Legacy classes in a module

[Stanley M. Ho]

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