<br><font size=2 face="sans-serif">Good point, so let's discuss the implications
on the JSR 294 list in due course as it would change the class loading
restrictions in the current 294 strawman. If you can expand on this aspect
at all before floating your proposal, it would help us all to work through
the implications.</font>
<br><font size=2 face="sans-serif"><br>
Glyn</font>
<br>
<br><font size=1 face="sans-serif"><b>Bryan Atsatt &lt;bryan.atsatt@ORACLE.COM&gt;</b></font><tt><font size=2>
wrote on 18/05/2007 19:42:27:<br>
<br>
&gt; No, we haven't yet, but we should.<br>
&gt; <br>
&gt; Another benefit you have may have spotted is that an OSGi implementation<br>
&gt; of 277 modules could support &quot;split superpackages&quot; by having
the loaders<br>
&gt; involved assign a common SuperPackage instance. While none of us likes<br>
&gt; split packages, if we are to truly make OSGi a first-class citizen
in<br>
&gt; the 277/294 world, this side-effect of the proposal should be seriously<br>
&gt; considered.<br>
&gt; <br>
&gt; // Bryan<br>
&gt; <br>
&gt; Glyn Normington wrote:<br>
&gt; &gt;<br>
&gt; &gt; Hi Bryan<br>
&gt; &gt;<br>
&gt; &gt; Your proposal has considerable benefits. Do you have a feel for
its<br>
&gt; &gt; acceptability to the JSR 294 Expert Group? I don't think we've
discussed<br>
&gt; &gt; it (properly) over there.<br>
&gt; &gt;<br>
&gt; &gt; Glyn<br>
&gt; &gt;<br>
&gt; &gt; *Bryan Atsatt &lt;bryan.atsatt@ORACLE.COM&gt;* wrote on 18/05/2007
03:01:09:<br>
&gt; &gt;<br>
&gt; &gt; &nbsp;&gt; I am assuming that in this scenario the module developer
would be<br>
&gt; &gt; &nbsp;&gt; allowed to make this explicit in the superpackage
declaration itself.<br>
&gt; &gt; &nbsp;&gt; That is, superpackage member declarations could include
packages from<br>
&gt; &gt; &nbsp;&gt; the &quot;legacy&quot; jars. 294 simply has to allow
declared member packages to<br>
&gt; &gt; &nbsp;&gt; be AWOL at compile time.<br>
&gt; &gt; &nbsp;&gt;<br>
&gt; &gt; &nbsp;&gt; BTW: The proposal I referred to earlier assumes that
the runtime<br>
&gt; &gt; &nbsp;&gt; artifact of a superpackage (e.g. a SuperPackage class
instance) is<br>
&gt; &gt; &nbsp;&gt; *assigned* to each class during ClassLoader.defineClass().
This<br>
&gt; &gt; &nbsp;&gt; decouples the superpackage and class file artifacts
while solving the<br>
&gt; &gt; &nbsp;&gt; superpackage &quot;loading&quot; problem for the VM.
It obviously makes it trivial<br>
&gt; &gt; &nbsp;&gt; for &quot;legacy&quot; classes to be assigned into
a superpackage as they are<br>
&gt; &gt; &nbsp;&gt; defined. (It also makes it possible to extend the
superpackage at<br>
&gt; &gt; &nbsp;&gt; runtime, but that may be going too far.)<br>
&gt; &gt; &nbsp;&gt;<br>
&gt; &gt; &nbsp;&gt; // Bryan<br>
&gt; &gt; &nbsp;&gt;<br>
&gt; &gt; &nbsp;&gt; Stanley M. Ho wrote:<br>
&gt; &gt; &nbsp;&gt; &gt; Regardless, I think we still need to distinguish
whether the legacy<br>
&gt; &gt; classes<br>
&gt; &gt; &nbsp;&gt; &gt; should be considered module private (use case
#1) or made visible<br>
&gt; &gt; externally<br>
&gt; &gt; &nbsp;&gt; &gt; (use case #2). I don't think we can really know
the developer's<br>
&gt; &gt; intent by<br>
&gt; &gt; &nbsp;&gt; &gt; looking at the legacy classes alone. Even if
rewriting is involved,<br>
&gt; &gt; we still<br>
&gt; &gt; &nbsp;&gt; &gt; need to distinguish these cases in order to have
the proper export<br>
&gt; &gt; &nbsp;&gt; &gt; information in the superpackage.<br>
&gt; &gt; &nbsp;&gt; &gt;<br>
&gt; &gt; &nbsp;&gt; &gt; - Stanley<br>
&gt; &gt; &nbsp;&gt; &gt;<br>
&gt; &gt; &nbsp;&gt; &gt;<br>
&gt; &gt; &nbsp;&gt; &gt; On Wed, 16 May 2007 14:17:54 -0700, Michal Cierniak<br>
&gt; &gt; &nbsp;&gt; &lt;cierniak@GOOGLE.COM&gt; wrote:<br>
&gt; &gt; &nbsp;&gt; &gt;<br>
&gt; &gt; &nbsp;&gt; &gt;&gt; I would like to add that even if superpackage
classes do name their<br>
&gt; &gt; &nbsp;&gt; &gt;&gt; superpackage in the new world, it wouldn't
be difficult to require the<br>
&gt; &gt; &nbsp;&gt; &gt;&gt; JRE to &quot;rewrite&quot; legacy classes
on the fly if they are loaded from a<br>
&gt; &gt; &nbsp;&gt; &gt;&gt; JAR embedded in a JAM. &nbsp;In that case,
the legacy classes would end up<br>
&gt; &gt; &nbsp;&gt; &gt;&gt; being members of the superpackage associated
with the containing JAM.<br>
&gt; &gt; &nbsp;&gt; &gt;&gt;<br>
&gt; &gt; &nbsp;&gt; &gt;&gt; We might run into other problems because
legacy classes do not<br>
&gt; &gt; &nbsp;&gt; &gt;&gt; necessarily play by the rules of the new
module-aware world but this<br>
&gt; &gt; &nbsp;&gt; &gt;&gt; is independent of whether we rewrite them
to add superpackage<br>
&gt; &gt; &nbsp;&gt; &gt;&gt; membership info.<br>
&gt; &gt; &nbsp;&gt; &gt;&gt;<br>
&gt; &gt; &nbsp;&gt; &gt;&gt; Michal<br>
&gt; &gt; &nbsp;&gt; &gt;&gt;<br>
&gt; &gt; &nbsp;&gt; &gt;&gt; On 5/16/07, Bryan Atsatt &lt;bryan.atsatt@oracle.com&gt;
wrote:<br>
&gt; &gt; &nbsp;&gt; &gt;&gt;&gt; While the current strawman suggests that
superpackage classes<br>
&gt; &gt; will have<br>
&gt; &gt; &nbsp;&gt; &gt;&gt;&gt; modified class files (e.g. naming their
superpackage), there is a<br>
&gt; &gt; &nbsp;&gt; &gt;&gt;&gt; proposal on the table that eliminates
this requirement.<br>
&gt; &gt; &nbsp;&gt; &gt;&gt;&gt;<br>
&gt; &gt; &nbsp;&gt; &gt;&gt;&gt; If eliminated, the only requirement to
include &quot;legacy&quot; classes in a<br>
&gt; &gt; &nbsp;&gt; &gt;&gt;&gt; superpackage will be to have the superpackage
artifact present.<br>
&gt; &gt; In a 277<br>
&gt; &gt; &nbsp;&gt; &gt;&gt;&gt; module, any mixture of new and &quot;legacy&quot;
classes (likely in separate<br>
&gt; &gt; &nbsp;&gt; &gt;&gt;&gt; jars) could then fall under the umbrella
superpackage. And this whole<br>
&gt; &gt; &nbsp;&gt; &gt;&gt;&gt; issue is eliminated...<br>
&gt; &gt; &nbsp;&gt; &gt;&gt;&gt;<br>
&gt; &gt; &nbsp;&gt; &gt;&gt;&gt; // Bryan<br>
&gt; &gt; &nbsp;&gt; &gt;&gt;&gt;<br>
&gt; &gt; &nbsp;&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; ------------------------------------------------------------------------<br>
&gt; &gt;<br>
&gt; &gt; /<br>
&gt; &gt; /<br>
&gt; &gt;<br>
&gt; &gt; /Unless stated otherwise above:<br>
&gt; &gt; IBM United Kingdom Limited - Registered in England and Wales
with number<br>
&gt; &gt; 741598.<br>
&gt; &gt; Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU/<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<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>