<br><font size=2 face="sans-serif">Hi Bryan</font>
<br>
<br><font size=2 face="sans-serif">Your proposal has considerable benefits.
Do you have a feel for its acceptability to the JSR 294 Expert Group? I
don't think we've discussed it (properly) over there.</font>
<br><font size=2 face="sans-serif"><br>
Glyn</font>
<br>
<br><font size=1 face="sans-serif"><b>Bryan Atsatt <bryan.atsatt@ORACLE.COM></b></font><tt><font size=2>
wrote on 18/05/2007 03:01:09:<br>
<br>
> I am assuming that in this scenario the module developer would be<br>
> allowed to make this explicit in the superpackage declaration itself.<br>
> That is, superpackage member declarations could include packages from<br>
> the "legacy" jars. 294 simply has to allow declared member
packages to<br>
> be AWOL at compile time.<br>
> <br>
> BTW: The proposal I referred to earlier assumes that the runtime<br>
> artifact of a superpackage (e.g. a SuperPackage class instance) is<br>
> *assigned* to each class during ClassLoader.defineClass(). This<br>
> decouples the superpackage and class file artifacts while solving
the<br>
> superpackage "loading" problem for the VM. It obviously
makes it trivial<br>
> for "legacy" classes to be assigned into a superpackage
as they are<br>
> defined. (It also makes it possible to extend the superpackage at<br>
> runtime, but that may be going too far.)<br>
> <br>
> // Bryan<br>
> <br>
> Stanley M. Ho wrote:<br>
> > Regardless, I think we still need to distinguish whether the
legacy classes<br>
> > should be considered module private (use case #1) or made visible
externally<br>
> > (use case #2). I don't think we can really know the developer's
intent by<br>
> > looking at the legacy classes alone. Even if rewriting is involved,
we still<br>
> > need to distinguish these cases in order to have the proper export<br>
> > information in the superpackage.<br>
> ><br>
> > - Stanley<br>
> ><br>
> ><br>
> > On Wed, 16 May 2007 14:17:54 -0700, Michal Cierniak <br>
> <cierniak@GOOGLE.COM> wrote:<br>
> ><br>
> >> I would like to add that even if superpackage classes do
name their<br>
> >> superpackage in the new world, it wouldn't be difficult to
require the<br>
> >> JRE to "rewrite" legacy classes on the fly if they
are loaded from a<br>
> >> JAR embedded in a JAM. In that case, the legacy classes
would end up<br>
> >> being members of the superpackage associated with the containing
JAM.<br>
> >><br>
> >> We might run into other problems because legacy classes do
not<br>
> >> necessarily play by the rules of the new module-aware world
but this<br>
> >> is independent of whether we rewrite them to add superpackage<br>
> >> membership info.<br>
> >><br>
> >> Michal<br>
> >><br>
> >> On 5/16/07, Bryan Atsatt <bryan.atsatt@oracle.com>
wrote:<br>
> >>> While the current strawman suggests that superpackage
classes will have<br>
> >>> modified class files (e.g. naming their superpackage),
there is a<br>
> >>> proposal on the table that eliminates this requirement.<br>
> >>><br>
> >>> If eliminated, the only requirement to include "legacy"
classes in a<br>
> >>> superpackage will be to have the superpackage artifact
present. In a 277<br>
> >>> module, any mixture of new and "legacy" classes
(likely in separate<br>
> >>> jars) could then fall under the umbrella superpackage.
And this whole<br>
> >>> issue is eliminated...<br>
> >>><br>
> >>> // Bryan<br>
> >>><br>
> ><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>