The future of Serialization

Alan Bateman Alan.Bateman at oracle.com
Mon Aug 11 14:18:20 UTC 2014


On 11/08/2014 13:06, Peter Firmstone wrote:
> Thanks Alan, I can relate to time poverty :)
>
> I might be assuming too much, but if there's interest in doing 
> something with Serialization, I'd be interested in learning about 
> plans or difficulties involved in deserialization and modules. It can 
> be a little more difficult to find the correct ClassLoader to resolve 
> classes during deserialization when ClassLoader relationships aren't 
> hierarchial.  Object streams can be annotated with module information 
> to assist resolution.
The issues around visibility when deserializing are somewhat independent 
of modules. The usual way to deal with such matters is to override the 
resolveClass method. Another long standing suggestion is for 
ObjectInputStream to define a new constructor that takes a class loader 
to avoid the stack walk to get the user-defined loader. It remains to 
seen but if we can avoid changing visibility then we don't change the 
status quo.
> :
>
> Got any links to info on extending access control rules?
Not yet, a future JSR will define the standard module system and there 
will be a corresponding JEP for the implementation.

-Alan.



More information about the core-libs-dev mailing list