Legacy classes in a module

[Bryan Atsatt]

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

Stanley M. Ho wrote:
> Hi JSR 277 experts,
>
> This is regarding the semantic of legacy classes in a module, and is one of
> the outstanding issues in the updated specification (Section 2.14) that I
> would like to get your inputs.
>
> Typically, classes in a module are "module" classes - Java classes that have
> superpackage membership. However, it is also possible that developers may
> want to make use of legacy classes in a module, e.g. using an existing xml
> parser in a module. There are two possible use cases I can think of:
>
> 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 the
> 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 or
> 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 level
> access control for the legacy classes, and there is not much we can do once
> the legacy classes are leaked out from the module classloader.
>
> That said, I think it's still important for us to define the semantics for
> 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) for
> developers to indicate the module is in the #2 category.
> c. If @ExportLegacyClasses is declared, the
> ModuleDefinition.getExportedClasses() would include the legacy classes.
>
> Note that unless this annotation is declared in the module definition, the
> 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 algorithm
> in 7.3.1, step 4). However, if other code obtains a reference of the module
> classloader somehow and invokes loadClass() directly with the legacy class
> name, the module classloader will still return the legacy class, and this is
> consistent with the existing classloader behavior.
>
> Let me know if you have inputs. If there are better ways to deal with this
> 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.
>