At 11:26 AM -0400 7/24/99, Doug Lea wrote:
>
> * Disallow escape of `this' before assignment to finals in constructors.
>
That is going to be very tricky to require. The problem is that your
super constructor could allow 'this' to escape (by storing it).
To disallow escape of `this' before assignment to finals in
constructors, you would either need to assign to finals before the
call to super, or just totally disallow the escape of this from a
constructor.
While these might be good language features, it isn't at all backward
compatible with existing Java code.
At 11:26 AM -0400 7/24/99, Doug Lea wrote:
>Can anyone think of a non-performance-based story about why final
>fields should ever be read, even by current (constructing) thread
>before they receive their values? Or why multiple assignments should
>ever be allowed?
Only that it isn't compatible with existing Java code.
At 11:26 AM -0400 7/24/99, Doug Lea wrote:
>
>(If not, then `final volatile' is superfluous, right?)
No. volatile is always superfluous for single threaded code
(excepting memory mapped IO). I consider the intuitive meaning of
"volatile" to mean:
"I'm going to have an unsynchronized data race on this variable"
If we decide that a data race allowing a thread to see the
"non-final" value of a final variable is a safety violation, then
"final volatile" is superfluous. But if we decide that it is simply
surprising (and perhaps likely to result in an error (e.g., a
NullPointerException)), then we can decide to allow the user to see
surprising results arising from his undeclared unsynchronized data
race. Declaring it as volatile would make it a declared data race, so
in that case we should probably require that the thread see the
correct final value.
Bill
-------------------------------
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email majordomo@cs.umd.edu and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:17 EDT