Fields initialization : initializers vs constructors

Question

I've just come to thought that I might be doing the wrong thing using initializers instead of initializing fields in the constructor. Of cause I'm speaking of DPL..
I'm used to do something like this:
@Persistent
class Compound
   private final Map<Integer, Integer> elements = new HashMap<Integer, Integer>();
   private Compound() {} //dummy private default constructor to be used by BDB
   //actual constructor to be used in the code
   public Compound(int initialValue)
     //some specific initialization...
     //e.g.:
     elements.add(initialValue, initialValue);
}But while thinking about what will BDB actually do when demarshaling the object instance, I came to idea that it would re-construct the elements map and forget the one I carefully create in the initializer.. So to avoid the useless object instantiation I'd have to initialize the field in constructor like this:
@Persistent
class Compound
   private final Map<Integer, Integer> elements;
   //dummy private default constructor to be used by BDB
   private Compound()
     //now I have to assign something to elements field because it's final..
     // or just remove the *final* modifier???
     elements = null;
   //actual constructor to be used in the code
   public Compound(int initialValue)
     elements = new HashMap<Integer, Integer>()
     //some specific initialization...
     //e.g.:
     elements.add(initialValue, initialValue);
}So my question is: is there any actual difference between the first and second approaches? Or I just thinking the wrong way?..

Answer 1

Hm.. Yes, I'm pretty sure it's working with JE. I was thinking that reflection allows bypassing the "final" modifier.. Hm.. Quick googling gives this for example: http://stuffthathappens.com/blog/2007/10/13/you-can-change-final-fields/. While reading this article it seems that it's still a bad idea to rely on it..
Interesting, thanks. I was probably remembering tests I performed on Java 1.4, which does not allow setting final fields, according to one of the comments.
Yes, relying on this behavior can get you into trouble for two reasons.
1. If the field happens to be public, JE will not call setAccessible.
2. If you're using the bytecode annotator, JE does not use reflection to set fields, and the generated code that changes the final field will fail.
The second issue is insidious, if you use the default reflection mechanism during initial development and then switch to bytecode generation later on.
I think JE should always throw an exception if the final modifier is set, to guard against this.
--mark