final transient fields serialization

[Pawel Veselov]

Hi Peter,

not at all, I was late on replying to all the answers I've got myself.

Anyway, my thoughts around this were that I wouldn't consider it reasonable
to put that much, and that kind of code around re-instantiation of final
transient fields, at least for the sheer sake of them being final.
Reflection means referencing fields using string values, and also places
significant overhead in the instructions that need to be executed (comparing
to what it took to create an object), the code that needs to be
written (makes for poor templating), and the kind of the operations that
need to be performed (needing security access, reflection itself is a shady
operation for a high level user code).

However, I don't really see any good way out of this situation, as final
fields are guaranteed instantiation during object construction, but there is
effectively no limit on how it can get assigned, and what other objects
would it use during such.

I would think that it would be reasonable to then allow the readObject() to
re-assign final transient fields under the same rules that currently apply
to setting final fields by constructors. I understand that this is as bad of
an idea, because readObject() can be called by other means, however, this
can be made into a compiler warning, or something, and throw some VM errors
if a final field is ever modified outside of the instantiation or
deserialization process. I know this is somewhat lame, but I'm not the VM
engineer :) But I still believe that the current state of things with final
and transient modifiers is somewhat troublesome.

Thanks,
  Pawel.

On Sun, Nov 29, 2009 at 1:05 PM, Peter Jones <pcj at roundroom.net> wrote:

> Pawel,
>
> Sorry for the late followup, but you might also want to read these RFEs:
>
> http://bugs.sun.com/view_bug.do?bug_id=6379948
> http://bugs.sun.com/view_bug.do?bug_id=6252102
>
> -- Peter
>
>
>
> On Nov 9, 2009, at 6:54 PM, David Holmes - Sun Microsystems wrote:
>
>  Pawel,
>>
>> Pawel Veselov said the following on 11/10/09 07:30:
>>
>>> it again caught my attention, and I though that may be there is something
>>> that can be done about this.
>>> The issue is obvious -- having 'final transient' instance fields makes
>>> little sense if the object is ever serialized.
>>> Logically, there may be perfect reasoning behind making an instance field
>>> final, as well as transient, in which case there is then no mechanism to
>>> reinitialize this field on object deserialization.
>>>
>>
>> Not quite true. This problem - that final fields can only be set during
>> true construction and not during the pseudo-construction that occurs during
>> deserialization - has been realized for a long time. As part of the Java 5
>> update we (I think it was done JSR-133) put in place the mechanism whereby
>> you can use reflection to set a final field provided that
>> setAccessible(true) has been invoked for that field. This is of course a
>> limited solution as you must have the security capability to invoke
>> setAccessible(true).
>>
>> JSR-133 also addresses the Java Memory Model issues concerning
>> deserialization of objects with final fields - see Section 17.5.3 of the
>> Java Language Specification. (The notion of a "freeze action" on a final
>> field was in part motivated by the deserialization issue).
>>
>> David Holmes
>>
>>  It seems that it would be nice if either the final fields were
>>> initialized in a separate block that would be executed on deserialization,
>>> or if readObject() could set them. After all you can have a code block that
>>> sets the final fields. Not sure how feasible that is, but IMHO, that is a
>>> short coming.
>>> --
>>> With best of best regards
>>> Pawel S. Veselov
>>>
>>
>


-- 
With best of best regards
Pawel S. Veselov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091129/2432055c/attachment.html>