Maybe this is too oddball a suggestion, but it sounds to me like what is
needed is a way to explicitly declare that an instance method may modify
an instance's otherwise-final fields. So, how about this?:
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.
As with removing "throws" specs in subclasses, it would be legit to
override a final-setting method with one that doesn't, but not vice
versa. Both checking this restriction and checking of putfields would be
straightforward additions to the verifier.
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.
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.
-dan
-------------------------------
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