Legacy classes in a module

[Glyn Normington]

Good point, so let's discuss the implications on the JSR 294 list in due
course as it would change the class loading restrictions in the current
294 strawman. If you can expand on this aspect at all before floating your
proposal, it would help us all to work through the implications.

Glyn

Bryan Atsatt <bryan.atsatt at ORACLE.COM> wrote on 18/05/2007 19:42:27:

> No, we haven't yet, but we should.
>
> Another benefit you have may have spotted is that an OSGi implementation
> of 277 modules could support "split superpackages" by having the loaders
> involved assign a common SuperPackage instance. While none of us likes
> split packages, if we are to truly make OSGi a first-class citizen in
> the 277/294 world, this side-effect of the proposal should be seriously
> considered.
>
> // Bryan
>
> Glyn Normington wrote:
> >
> > Hi Bryan
> >
> > Your proposal has considerable benefits. Do you have a feel for its
> > acceptability to the JSR 294 Expert Group? I don't think we've
discussed
> > it (properly) over there.
> >
> > Glyn
> >
> > *Bryan Atsatt <bryan.atsatt at ORACLE.COM>* wrote on 18/05/2007 03:01:09:
> >
> >  > I am assuming that in this scenario the module developer would be
> >  > allowed to make this explicit in the superpackage declaration
itself.
> >  > That is, superpackage member declarations could include packages
from
> >  > the "legacy" jars. 294 simply has to allow declared member packages
to
> >  > be AWOL at compile time.
> >  >
> >  > BTW: The proposal I referred to earlier assumes that the runtime
> >  > artifact of a superpackage (e.g. a SuperPackage class instance) is
> >  > *assigned* to each class during ClassLoader.defineClass(). This
> >  > decouples the superpackage and class file artifacts while solving
the
> >  > superpackage "loading" problem for the VM. It obviously makes it
trivial
> >  > for "legacy" classes to be assigned into a superpackage as they are
> >  > defined. (It also makes it possible to extend the superpackage at
> >  > runtime, but that may be going too far.)
> >  >
> >  > // Bryan
> >  >
> >  > Stanley M. Ho wrote:
> >  > > Regardless, I think we still need to distinguish whether the
legacy
> > classes
> >  > > should be considered module private (use case #1) or made visible
> > externally
> >  > > (use case #2). I don't think we can really know the developer's
> > intent by
> >  > > looking at the legacy classes alone. Even if rewriting is
involved,
> > we still
> >  > > need to distinguish these cases in order to have the proper
export
> >  > > information in the superpackage.
> >  > >
> >  > > - Stanley
> >  > >
> >  > >
> >  > > On Wed, 16 May 2007 14:17:54 -0700, Michal Cierniak
> >  > <cierniak at GOOGLE.COM> wrote:
> >  > >
> >  > >> I would like to add that even if superpackage classes do name
their
> >  > >> superpackage in the new world, it wouldn't be difficult to
require the
> >  > >> JRE to "rewrite" legacy classes on the fly if they are loaded
from a
> >  > >> JAR embedded in a JAM.  In that case, the legacy classes would
end up
> >  > >> being members of the superpackage associated with the containing
JAM.
> >  > >>
> >  > >> We might run into other problems because legacy classes do not
> >  > >> necessarily play by the rules of the new module-aware world but
this
> >  > >> is independent of whether we rewrite them to add superpackage
> >  > >> membership info.
> >  > >>
> >  > >> Michal
> >  > >>
> >  > >> On 5/16/07, Bryan Atsatt <bryan.atsatt at oracle.com> wrote:
> >  > >>> While the current strawman suggests that superpackage classes
> > will have
> >  > >>> modified class files (e.g. naming their superpackage), there is
a
> >  > >>> proposal on the table that eliminates this requirement.
> >  > >>>
> >  > >>> If eliminated, the only requirement to include "legacy" classes
in a
> >  > >>> superpackage will be to have the superpackage artifact present.
> > In a 277
> >  > >>> module, any mixture of new and "legacy" classes (likely in
separate
> >  > >>> jars) could then fall under the umbrella superpackage. And this
whole
> >  > >>> issue is eliminated...
> >  > >>>
> >  > >>> // Bryan
> >  > >>>
> >  > >
> >
> >
> >
> >
------------------------------------------------------------------------
> >
> > /
> > /
> >
> > /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/
> >
> >
> >
> >
> >
> >






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: http://mail.openjdk.java.net/pipermail/jsr277-eg-observer/attachments/20070519/86dabb40/attachment.html