Legacy classes in a module

[Bryan Atsatt]

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