Legacy classes in a module

[Stanley M. Ho]

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