Legacy classes in a module

[Glyn Normington]

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jsr277-eg-observer/attachments/20070518/e7722aff/attachment.html