Legacy classes in a module

Glyn Normington glyn_normington at UK.IBM.COM
Wed May 16 07:09:43 PDT 2007

Hi Stanley

"Stanley M. Ho" <stanley.ho at SUN.COM> wrote on 16/05/2007 07:39:10:

> Hi JSR 277 experts,
> This is regarding the semantic of legacy classes in a module, and is one
> the outstanding issues in the updated specification (Section 2.14) that
> would like to get your inputs.
> Typically, classes in a module are "module" classes - Java classes that
> superpackage membership. However, it is also possible that developers
> want to make use of legacy classes in a module, e.g. using an existing
> parser in a module. There are two possible use cases I can think of:

I can't tell from this whether the developer has the freedom to recompile
the legacy classes, but I assume not otherwise it would be trivial to
include them as superpackage members. (Also, there are use cases where a
developer needs to use an existing JAR, but doesn't have the source or the
rights to crack the JAR open and fiddle with the contents.)

> 1. Developers simply make use of the legacy classes as implementation
> details in the module. In this case, the exported module classes neither
> expose nor reference the legacy classes in the export signatures, and
> legacy classes in the module should not be made visible to the importing
> modules.
> 2. Developers use the legacy classes as part of the public API in the
> module. In this case, the legacy classes in the module should be made
> visible to the importing modules. The exported module classes may expose
> reference the legacy classes in the export signatures, but this is
> not required.
> I think it's important for us to recognize and support both use cases.
> However, this may be difficult for us to determine which use case is the
> developers' real intention. Adding to the mix is that lack of module
> access control for the legacy classes, and there is not much we can do
> the legacy classes are leaked out from the module classloader.
> That said, I think it's still important for us to define the semantics
> both use cases in the specification. Here is what I propose:
> a. Consider #1 to be the default.


> b. Add a new superpackage-level annotation (e.g. @ExportLegacyClasses)
> developers to indicate the module is in the #2 category.

Note that this does not enable a developer to expose some but not all of
the legacy classes in a module.

> c. If @ExportLegacyClasses is declared, the
> ModuleDefinition.getExportedClasses() would include the legacy classes.
> Note that unless this annotation is declared in the module definition,
> importing modules will never attempt to load the legacy classes from the
> imported module during classloading delegation as the classloading
> delegation algorithm always checks getExportedClassed() first (see
> in 7.3.1, step 4). However, if other code obtains a reference of the
> classloader somehow and invokes loadClass() directly with the legacy
> name, the module classloader will still return the legacy class, and
this is
> consistent with the existing classloader behavior.

Is this proposal meant to include the case of creating a module from
legacy classes alone? If so, I guess the module would need an 'empty'
superpackage definition such as:

superpackage org.apache.xerces {}

> Let me know if you have inputs. If there are better ways to deal with
> issue, I would like to hear them as well.
> - Stanley
> P.S. This is also a repost due to email problems. Please ignore if you
> receive more than one copy of this message.


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jsr277-eg-observer/attachments/20070516/5d656731/attachment.html 

More information about the jsr277-eg-observer mailing list