Dan Bornstein wrote:
> Define a new bit on the access flags for methods, and have it
> indicate that possibility. With the flag on, you could allow normal
> putfields (normal field setting syntax) to work for final fields, and
> not have to go through handsprings with Field.set() though, of
> course, that could be made to work too and it would make sense to do
> so in order to support existing code with a minimum of fuss. The vm
> (and user) would have enough info to behave well (and code well) with
> respect to calling such a method.
The major problem with this is that we aren't really allowed (or we
weren't, with JSR-133) to mess with the language or bytecode. The
"powers that be" actually prefer to make changes in APIs.
But this is okay (in this case), because we can provide the same thing
with API calls. Which is roughly what I suggesting. We have the notion
of a final field safe region to play with. As long as there is
explicitly a way to declare a final field safe region using an API,
there isn't actually a need to change the language.
> This system avoids having to have the vm or library have a laundry
> list of explicit special cases, and it particularly leaves enough
> leeway for people to write new serialization-like systems in a pretty
> direct and sensible way.
The libraries would have to have a laundry list of explicit special
cases anyway, because each individual call would have to be defined to
require the proposed access flag.
And having an API lets people use it.
> And of course Java the language and Java the vm already have a
> keyword and flag which have just about the right implications and are
> as-yet undefined on methods: "volatile" 0x0040.
"volatile" meaning "final field safe" seems really ugly to me. If
"volatile" were to be used for methods ever, I would much rather have it
mean something like "atomic".
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