Final attributtes? -- None Standard-Constructor?

Urmech · **Joined:** Thu Apr 14, 2005 10:39 am **Posts:** 115

Hi,

is it possible to tell Hibernate to use an none standard constructor?

I need to use an none standard constructor to set final attributes.

Like you can do it with XML-Encoder.
See:
XMLEncoder Customizing Instantiation --
Constructors whose arguments are properties
http://java.sun.com/products/jfc/tsc/articles/persistence4/

Which Annotation do I have to use?

Is @Immutable a solution?

Thanks a lot in advance.

Greetings Michael

emmanuel · **Posted:** Fri Jan 04, 2008 7:45 am

No, this is not possible. But you could make your setters private (or use field access)

Urmech · **Joined:** Thu Apr 14, 2005 10:39 am **Posts:** 115

Hi,

thanks for the quick reply.

Can you tell me why this isn't possible?

Cause the Java-API should be no problem (at least since Java5)

Code:

getConstructor(Class<?>... parameterTypes)

in

Code:

java.lang.Class<T>

and

Code:

public T newInstance(Object... initargs)

in

Code:

java.lang.reflect.Constructor<T>

So if hibernate would know the signature, it should be able to find the correct constructor.

Is it planed to be supported in future releases?

Thanks.

Greetings Michael

emmanuel · **Posted:** Fri Jan 04, 2008 2:28 pm

I am not saying it's physically impossible, it's not implemented in Hibernate. The request level for that stayed fairly marginal over the years, so it did not worth the effort.

Urmech · **Joined:** Thu Apr 14, 2005 10:39 am **Posts:** 115

Quote:

I am not saying it's physically impossible, it's not implemented in Hibernate. The request level for that stayed fairly marginal over the years, so it did not worth the effort.

Hi emmanuel, it's a little bit pitty that it isn't supported yet and may not be supported in the future.

Cause it forces changes to your normal Java-Code and makes used patterns not obviously and may corrupt them. Even private and attribute access are already limiting that drawbacks.

E.G. if you use the immutable pattern, avoiding the keyword "final" may be misleading and you aren't aware (No Compiler-Error) anymore that you don't change the value accidentally in the code of the given class itself. So even the request-level may not worth the effort, the effort may be worth to support better code.

Greetings Michael

emmanuel · **Posted:** Mon Jan 07, 2008 9:47 am

Yes but provided that the final keyword is not what you want it to be semantically in Java (think about array, collections etc), we all know that we live in an imperfect world :)
If you come up with a good patch, Steve or Gail might apply it, and you sure will be able to use it.