final transient fields serialization

[Tom Hawtin]

Peter Jones wrote:

> Regarding a language solution, though, I don't see how to avoid making a 
> [...]

`readObject` is a `psuedo-constructor`. Ideally it would be a real 
constructor (with choice of defaultReadObject/readFields similar to 
super), but that would require significant changes to the JLS.

Similar problems appear for JAXB, ORMs, etc. Dependency Inject also has 
problems with construction. Construction often involves way too much 
boilerplate. There are lots of issues here, most I have little 
experience with.

> So I think that the best hope is an improved reflective library 
> solution.  Thinking out loud: say, a factory method that looks up a 
> [...]

I guess something like

class MyClass implements Serializable {
     private final transient Thing thing;
     private static final FieldRead<Thing> THING_READER =
         FieldRead.newInstance("thing");
     ...
     private void readObject(...) ... {
         in.defaultReadObject();
         Thing thing = (Thing)in.readObject();
         THING_READER.set(thing);
     }
}

Gratuitous use of immediate caller. I just know people will attempt to 
take client supplied arguments. Best we can do is put a few static 
checks in javac and static analysis tools, and runtime checks into the 
serialisation mechanism.

(Notes:
    FieldRead.newInstance
      - must be called by static initialiser
          (dynamic and perhaps static check).
      - static analysis (inc. javac) can check field name, type and 
assignment).
      - errors by unchecked exception
    FieldRead.read
      - Dynamic check that called from readObject on this instance (can 
cheat).
      - Dynamic check for no reassignment.
      - Dynamic check after readObject call for definite assignment.
      - Could also add static checks as well.
)

Tom Hawtin