Explicit Serialization API and Security

Chris Hegarty chris.hegarty at oracle.com
Wed Jan 14 11:37:26 UTC 2015

Peter F,

I am still struggling with the basic concept of you proposal. Let me see 
if I understand it correctly. Does the following describe a similar 
scenario as you envisage:

  1) For each Serializable type, T, in the deserialized types
     hierarchy, starting with the top most ( closest to j.l.Object ),

     1a) Read T's fields from the stream, fields

     1b) validate(t, fields)  // t will be null first time

     1c) allocate a new instance of T, and assign to t

     1d) set fields in t

  2) Return t;

So for each level in the hierarchy, an instance of a type is created 
only after its invariants have been checked. This instance is then 
passed to the next level so it can participate in that levels invariants 

If this scenario is along the same lines as yours, then I just don't see 
how 1c above will always be possible.

If we could somehow make the object caller sensitive until after 
deserialization completes, then could avoid having to try to allocate 
multiple instance down the hierarchy.


On 13/01/15 10:24, Peter Firmstone wrote:
> Could we use a static validator method and generate bytecode for
> constructors dynamically?
> The developer can optionally implement the constructors.
> static GetField invariantCheck(GetField f);
> Create a caller sensitive GetField implementation and add a two new
> methods to GetField:
> abstract Object createSuper(); // to access superclass object methods
> for inavariant checking.
> abstract Class getType(String name);
> Set fields from within constructors.
> The generated constructors are straight forward:
> 1. Call static method.
> 2. Call super class constructor with result from static method.
> 3. Set final fields
> 4. How to set transient fields, implement a private method called from
> within the constructor?
> Require a permission to extend GetField?

More information about the core-libs-dev mailing list