Legacy classes in a module

[Stanley M. Ho]

Hi Glyn,

On Wed, 16 May 2007 15:09:43 +0100, Glyn Normington
<glyn_normington at UK.IBM.COM> wrote:

>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.)

Yes, this is to address the situation where the developer does not have the
freedom to recompile the legacy classes but he still want to make use of
them in the module.

>> b. Add a new superpackage-level annotation (e.g. @ExportLegacyClasses)
>for
>> 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.

Right. It should be very easy if we want to change it to support finer
granularity, but I would like to keep it simple for now.

>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:
>
>@Version("2.9.0")
>@ExportLegacyClasses
>superpackage org.apache.xerces {}

No, this proposal is only intended to address the first bullet in Section
2.14 in the updated specification. If the developer has the rights to
repackage the legacy classes with the module metadata, most likely he also
has access to the source thus he has the freedom to recompile, and I think
the recommendation would be for him to migrate the legacy JAR to be a simple
module archive.

- Stanley