<br><font size=2 face="sans-serif">Hi Stanley</font>
<br>
<br><font size=1 face="sans-serif"><b>"Stanley M. Ho" <stanley.ho@SUN.COM></b></font><tt><font size=2>
wrote on 16/05/2007 07:39:10:<br>
<br>
> Hi JSR 277 experts,<br>
> <br>
> This is regarding the semantic of legacy classes in a module, and
is one of<br>
> the outstanding issues in the updated specification (Section 2.14)
that I<br>
> would like to get your inputs.<br>
> <br>
> Typically, classes in a module are "module" classes - Java
classes that have<br>
> superpackage membership. However, it is also possible that developers
may<br>
> want to make use of legacy classes in a module, e.g. using an existing
xml<br>
> parser in a module. There are two possible use cases I can think of:</font></tt>
<br>
<br><tt><font size=2>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.)</font></tt>
<br><tt><font size=2><br>
> <br>
> 1. Developers simply make use of the legacy classes as implementation<br>
> details in the module. In this case, the exported module classes neither<br>
> expose nor reference the legacy classes in the export signatures,
and the<br>
> legacy classes in the module should not be made visible to the importing<br>
> modules.<br>
> <br>
> 2. Developers use the legacy classes as part of the public API in
the<br>
> module. In this case, the legacy classes in the module should be made<br>
> visible to the importing modules. The exported module classes may
expose or<br>
> reference the legacy classes in the export signatures, but this is
<br>
> not required.<br>
> <br>
> I think it's important for us to recognize and support both use cases.<br>
> However, this may be difficult for us to determine which use case
is the<br>
> developers' real intention. Adding to the mix is that lack of module
level<br>
> access control for the legacy classes, and there is not much we can
do once<br>
> the legacy classes are leaked out from the module classloader.<br>
> <br>
> That said, I think it's still important for us to define the semantics
for<br>
> both use cases in the specification. Here is what I propose:<br>
> <br>
> a. Consider #1 to be the default.</font></tt>
<br>
<br><tt><font size=2>Agreed.</font></tt>
<br><tt><font size=2><br>
> b. Add a new superpackage-level annotation (e.g. @ExportLegacyClasses)
for<br>
> developers to indicate the module is in the #2 category.</font></tt>
<br>
<br><tt><font size=2>Note that this does not enable a developer to expose
some but not all of the legacy classes in a module.</font></tt>
<br><tt><font size=2><br>
> c. If @ExportLegacyClasses is declared, the<br>
> ModuleDefinition.getExportedClasses() would include the legacy classes.<br>
> <br>
> Note that unless this annotation is declared in the module definition,
the<br>
> importing modules will never attempt to load the legacy classes from
the<br>
> imported module during classloading delegation as the classloading<br>
> delegation algorithm always checks getExportedClassed() first (see
algorithm<br>
> in 7.3.1, step 4). However, if other code obtains a reference of the
module<br>
> classloader somehow and invokes loadClass() directly with the legacy
class<br>
> name, the module classloader will still return the legacy class, and
this is<br>
> consistent with the existing classloader behavior.</font></tt>
<br>
<br><tt><font size=2>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:</font></tt>
<br>
<br><tt><font size=2>@Version("2.9.0")</font></tt>
<br><tt><font size=2>@ExportLegacyClasses</font></tt>
<br><tt><font size=2>superpackage org.apache.xerces {}</font></tt>
<br>
<br><tt><font size=2>> <br>
> Let me know if you have inputs. If there are better ways to deal with
this<br>
> issue, I would like to hear them as well.<br>
> <br>
> - Stanley<br>
> <br>
> P.S. This is also a repost due to email problems. Please ignore if
you<br>
> receive more than one copy of this message.</font></tt>
<br>
<br><tt><font size=2>Glyn<br>
</font></tt><font size=3 face="sans-serif"><br>
</font>
<br><font size=3 face="sans-serif"><br>
</font>
<hr><font size=2 face="sans-serif"><br>
<i><br>
</i></font>
<p><font size=2 face="sans-serif"><i>Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU</i></font>
<p><font size=2 face="sans-serif"><br>
</font><font size=3 face="sans-serif"><br>
</font>
<br>
<br><font size=3 face="sans-serif"><br>
</font>