The future of Serialization

[Peter Firmstone]

Interesting, language features for modules, won't necessarily involve ClassLoader's (my assumptions were based on existing systems) although you'd expect modules to have their own ProtectionDomain.

An alternative to isolates, is separate processes with jvm class sharing enabled.

I'll keep an eye out for the JSR.

When is a better timeframe, roughly, to discuss Serializable?

Regards,

Peter.

----- Original message -----
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20140812/0cc28fbc/attachment.htm>