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 <p...@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
