Jeremy Manson wrote:
> 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.
Jep, but I didn't initizialized them in the constructor but in the class
If one would know that the constructor is the first and only entry point
of a class _and_ that final fields would be first accessibly _after_ the
super constructor was executed _then_ everything makes sense.
But the allowed syntax suggest a different semantic because these kind
of fields are independent of the constructor.
Having final fields (initialized in the class body) created before the
the call of a constructor would be a similar semantic to static fields
and would ease subclassing and method oveloading.
> 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.
This shouldn't be a too difficult :-)
> 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
> Yes. It is extremely misleading. And it has implications for
> multithreading. Unfortunately, we're stuck with it. Another case of
> premature optimization run amok.
I tried it again by setting the int to "(int) (1000 * Math.random())",
which behaves like the object field, the real value is seen after the
>> 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).
Again the solution is based on an exception, that's what I don't like
about the current behaviour. Why should it not be possible to use the
(class body initialized) final field? It would (maybe) make code safer
and easier to write (at least it wouldn't make it worse).
Would there be any disadvantage to have final fields initialized before
the constructor call? Would it break compability?
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