Legacy classes in a module

[Bryan Atsatt]

Of course--we can revisit this if 294 adopts my proposed model...

// Bryan

Stanley M. Ho wrote:
> Hi Bryan,
>
> On Thu, 17 May 2007 19:01:09 -0700, Bryan Atsatt <bryan.atsatt at ORACLE.COM>
> wrote:
>
>> 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.
>
>>From the perspective of JSR 277, I think what we need is simply a way to
> determine from the module metadata whether/which legacy classes should be
> made visible externally or not, and this is orthogonal to how it is
> expressed in the syntax in JSR 294.
>
> Because it is unclear how legacy classes will be handled in JSR 294, I am
> assuming that the module developer would make this explicit in the form of
> metadata annotation with the superpackage. Do you have any problem if we go
> with the @ExportLegacyClasses proposal for now so we can move on to other
> issues?
>
>> 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
>
> The proposal you referred to is in the scope of JSR 294 but out of the scope
> of JSR 277, so I think it will be more appropriate if you raise and discuss
> that proposal with the JSR 294 EG.  ;)
>
> - Stanley
>