The future of Serialization
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
> 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.
More information about the core-libs-dev