"David Holmes" <dholmes@dstc.edu.au> wrote:
> This is, unfortunately, a very murky issue. Serialization is broken
because
> it doesn't allow for the setting of final fields in readObject - hence the
> work-around (now that reflection won't let you do it) of using JNI.
> De-Serialization acts as a defacto constructor but it doesn't have the
> privileges that a constructor has, of being able to set a final field. The
> whole interaction of final fields and serialization is a mess. If you ever
> find the need to mark a field as "transient final" then watchout. The
simple
> solution is to stop using final fields - but that's not a very good
> solution.
I think there shouldn't be a problem with JNI creating some object and
setting its (possibly final) fields, and then "giving it to the VM" since
the VM has never seen it before and has yet to make any assumptions about
the final fields.
If the object has to be "given to the VM" as a by-product of construction,
then maybe there could be some low-level JNI accessible way of telling the
VM that this new object isn't "done" yet, and then later tell the VM that it
is "done". Constructors for objects that have final fields could work
similarly under the hood.
I do not know JNI one bit, nor most lower level VM stuff... so I don't know
if this makes sense; please comment.
> The whole System.* business is a complete debacle but one we are stuck
with
> forever. It is abhorrent that it must be special cased.
I think that if Sun changed their mind about how to get at System.out and
decided to instead have System.getOut(), but they didn't want to break old
code, then they could do some fancy "class re-writing" to mutate old code.
The technique is fancy and non-trivial, but of all things that can be done
with class-rewriting, this isn't hard.
> I would be much happier if JNI disallowed the changing of final fields,
but
> unless the de-serialization issue if fixed (and the System.* - though that
> will probably remain special cased in the VM regardless) the JNI can't be
> changed. Given that, the JMM need only deal with this issue in the context
> of the visibility guarantees it makes for construction.
I agree.
-- David Smiley
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:31 EDT