Jeremy Manson wrote:
> It is unclear what you mean by "would something like this work".
In a perfect world final fields as the one in the example would be
initialized before anything else (including the constructor) so that
access to these fields is guaranteed. IMO the current behaviour is
misleading and limiting.
> In your case, the answer is that final fields are initialized after
> the call to super(). The program you gave below will initially invoke
> super(), which calls writeMembers(). writeMembers() will print:
>
> null
> -10
>
> because the integer "value" is compiled as a constant. When control
> returns to the subclass initializer, it will initialize the map, and
> print:
>
> {}
> -10
>
My example was very simple but problems alike will occur because
overloading will lead to problems. I just looked up the source of
JTable and found the problem I had; the setModel() cannot be overloaded
to use a delegating model (e.g for sorting) because setModel() is called
by the default constructor and therefore the delegating model wouldn't
exist at this time. My original solution was a " 3 liner" but it didn't
work due to these limitations.
> It is generally important _not_ to access final fields before they
> have been initialized. It is also important to ensure that other
> threads do not access the final fields of an object before the end of
> the object's constructor.
>
From my POV the final field has been accesseed and initialized _before_
the contructor was called, at least there is no dependency on the
constructor to initialize this kind of fields.
Still my question, would this code behave different with the new memory
model.?
Victor
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:09 EDT