Victor Toni wrote:
> Still my question, would this code behave different with the new memory
> model.?
The new memory model addresses issues of multithreading. It mostly
revises Chapter 17 of the JLS, Threads and Locks. Where it touches
final field initialization, it is to address issues of multithreading.
It does not address source code to bytecode compilation, which is what
this is.
To put it another way, this has nothing to do with JSR-133, and the
semantics remain the same. Sorry.
> 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.
There are, to my mind, issues here:
1) Is it misleading to have variable initializers take place after calls
to this() and super()?
Every book on Java says that calls to this() and super() are explicitly
the first thing that happens in a constructor. It can't be too
misleading. This:
> From my POV the final field has been accessed and initialized
> _before_ the constructor was called, at least there is no dependency
> on the constructor to initialize this kind of fields.
is simply not what the semantics of Java are. I don't mean to sound
harsh, but you'll have to adjust your POV.
There are fairly good reasons for this. It is not good, for example,
for a superclass's constructor to step on what is done by a subclass's
constructor. By executing the superclass's constructor first, this can
be avoided.
2) Is it misleading for final primitive variables to be compiled into
constants, and appear as if they are initialized first, when others aren't?
Yes. It is extremely misleading. And it has implications for
multithreading. Unfortunately, we're stuck with it. Another case of
premature optimization run amok.
> 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.
Or, setModel() could initialize the variables that aren't initialized
yet (assuming they aren't final).
Jeremy
-------------------------------
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