Legacy classes in a module

[Bryan Atsatt]

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/
>
>
>
>
>
>