> Did anything get decided about how a class can perform custom
> deserialization of transient final fields?
>
> Although not strictly a JMM issue, it has become more interesting as a
> result of the new final field semantics. I'm already being frustrated by
> the need to choose between default serialization and making the field
> volatile. Using reflection is not an option if ones class is to run in an
> environment where it is not trusted to use setAccessible.
In JDK1.5, using setAccessible is the only way to reflectively
set final fields.
>
> There was some discussion of allowing readObject() constructor-like rights
> regarding final fields, but nothing definite was said.
The main snag here is that this doesn't address similar problems
encountered in Object.clone(), as well as any methods that act like
deserialization, but don't go through readObject. So there's not any
single call-stack check that would suffice. The only suggestion I've
heard that works is to allow reflective sets of final fields from
within any "private" method, but this is so broad that it would invite
too many errors and add to the ways that people can introduce
insecurities.
So for now, I think the issue is tabled until someone comes up with a
better solution. Until then, you can only refelectively set finals
in trusted code.
-Doug
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:08 EDT