Legacy classes in a module
Stanley M. Ho
Stanley.Ho at sun.com
Fri May 18 12:23:27 PDT 2007
Bryan Atsatt 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.
Since 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 in JSR 277 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 the proposal with the JSR 294 EG. ;)
More information about the jsr277-eg-observer