Legacy classes in a module

[Michal Cierniak]

Yes, I was only addressing one aspect of the problem.

On 5/17/07, Stanley M. Ho <stanley.ho at sun.com> 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
> >>
>