[jsr294-modularity-eg] Runtime model

[Glyn Normington]

Bryan Atsatt <bryan.atsatt at oracle.com> wrote on 28/06/2007 11:28:30 PM:

> 
> 
> Glyn Normington wrote:
> > 
> > *Andreas Sterbenz <Andreas.Sterbenz at sun.com>* wrote on 14/06/2007 
> > 06:35:48 PM:
> > 
> >  > Glyn Normington wrote:
> >  > >
> >  > > Further to my comments below, I'd like us to explore why loading 
a
> >  > > legacy class into a superpackage would be deemed to be changing, 
> > rather
> >  > > than compatibly extending, its semantics?
> >  >
> >  > Sure. I think we should start by examining the use cases. Some of 
the
> >  > questions in my mind are:
> >  >
> >  > When is it is necessary to dynamically draft legacy classes into 
the
> >  > superpackage?
> > 
> > To allow applications to support multiple versions of Java and exploit 

> > superpackages on Java 7. We should remember that at least in the first 

> > few years of Java 7, the world will be mainly at Java 5 or 6 and 
> > application writers won't want to restrict their market to a fraction 
of 
> > the total.
> > 
> > If we don't support this use case, then the only applications that 
will 
> > exploit superpackages are those which are being written from scratch 
or 
> > rewritten specifically for Java 7. This will be a small minority of 
> > applications until the world is mainly at Java 7 in, perhaps, a decade 

> > or so.
> > 
> >  >
> >  > Why are approaches that expose classes that are a member of a 
> > superpackage
> >  > and legacy classes as one "component" (module, bundle, etc.) not
> >  > sufficient? They can coexist just fine.
> > 
> > Agreed, but this would delay the uptake of superpackages.
> > 
> >  >
> >  > Another approach is static class file rewriting. When is that not 
> > sufficient?
> > 
> > Whether this use case is supported by re-defining the semantics of 
> > existing compiled code or automatically re-writing the classes is a 
> > detail we can work out if we agree we should support the use case. I 
> > agree class rewriting is probably sufficient, but I'm not sure the 
> > significant extra complexity is necessary.
> 
> 
> If by "static" here you mean at development time, then yes, this may be 
> a reasonable solution: create a tool to take legacy classes and inject a 

> superpackage name. This implies upgrading the class file version, 
> doesn't it? If so, that may be more complex. Obviously it is easy to add 

> an appropriate .spkg file to a jar or a module.
> 
> The use case I have in mind is the module developer who must bundle 
> "legacy" binaries, but would like to limit external access to those 
> classes. Since the module system relies on superpackages to impose 
> access control, it will be impossible to support any export policy other 

> than "all" without a mechanism to bind legacy classes into a 
superpackage.
> 
> While I think development time class rewriting is likely a decent 
> solution, it would be unreasonably complex/expensive if deferred to 
> runtime. Does anyone have a use case for binding legacy classes to a 
> superpackage at runtime?

Yes - the one above! ;^) If we only support the development time class 
rewriting solution, then in that scenario, I suspect an application 
developer would probably choose not to bother with superpackages rather 
than have to build, ship, and maintain a separate version of the 
application specifically for Java 7 and beyond.

I'd estimate this would defer the widespread adoption of superpackages by 
7-10 years. (This may seem pessimistic, but I think the majority of 
application developers are only just becoming comfortable hard pre-req'ing 
Java 5 and the generics JSR was at roughly the stage JSR 294 is at now 
about 7 years ago. Plus I'd expect the rate of migration to new releases 
to slow down rather than speed up in the future.)

Glyn

> 
> // Bryan
> 
> > 
> > Glyn
> > 
> >  >
> >  > Andreas.
> >  >
> >  > _______________________________________________
> >  > jsr294-modularity-eg mailing list
> >  > jsr294-modularity-eg at cs.oswego.edu
> >  > http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
> > 
> > 
> > 
> > 
------------------------------------------------------------------------
> > 
> > /
> > /
> > 
> > /Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with 
number 
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU/
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
------------------------------------------------------------------------
> > 
> > _______________________________________________
> > jsr294-modularity-eg mailing list
> > jsr294-modularity-eg at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU





-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070629/5d46c8e7/attachment.html