<br><font size=1 face="sans-serif"><b>Bryan Atsatt <bryan.atsatt@ORACLE.COM></b></font><tt><font size=2>
wrote on 23/05/2007 20:52:47:<br>
<br>
> Stanley M. Ho wrote:<br>
> >> I think we need to think hard about this issue. The OSGi
model of import<br>
> >> by *package name* decouples the importer from any explicit
binding to a<br>
> >> bundle/module name. Refactoring under that model is *much*
cleaner, and<br>
> >> far more natural. As is the usage model. After all, Foo.java
import<br>
> >> statements contain package/class names, *not* module names.
Programmers<br>
> >> think in terms of classes and packages.<br>
> >><br>
> >> Peter makes this point pretty strongly, and I have to say
I agree<br>
> >> wholeheartedly:<br>
> >><br>
> >> http://www.aqute.biz/Blog/2006-04-29<br>
> ><br>
> > I agreed that in some situations it is much better to have dependency<br>
> > that is loosely coupled. You may want to check out the service-providers<br>
> > strawman that I just sent out, and it deals with the exact issue
around<br>
> > API vs implementation.<br>
> <br>
> That's great, but sort of beside the point :^).<br>
> <br>
> I am specifically referring to the syntax and semantics of "import"<br>
> declarations. At the moment, 277 supports only the "Reguire Bundle"<br>
> style semantics defined by OSGi. This model is is inherently<br>
> tightly-coupled, and its use is greatly discouraged in the OSGi world.<br>
> It was not even present in the initial releases.<br>
> <br>
> I strongly believe that it would be a huge mistake for 277 to support<br>
> only this model. If we want to simplify things and support only one<br>
> model, then we should choose import by package name/version, *not*<br>
> import by module name/version.<br>
</font></tt>
<br><tt><font size=2>Of course "import package" is superior to
"require bundle" in many situations, but I think it would be
a vast waste of time for JSR 277 to play "catch-up" with JSR
291.</font></tt>
<br>
<br><tt><font size=2>A better approach would be for the Java 7 platform
to provide first class support for JSR 291. This boils down to standardising
the experimental class loader deadlock fix ([1]) and enabling JSR 291 to
exploit JSR 277's repositories and JSR 294's superpackages.</font></tt>
<br>
<br><tt><font size=2>The features in JSR 277 which are already provided
by JSR 291 could be ditched (!) or could be retained for users wanting
a module system "out of the box" or for exploitation by the JRE
itself as a properly architected sequel to the consumer JRE. But if we
retain these features, it is essential we provide first-class interoperation
with JSR 291 as we have discussed many times in the past but which still
looks pretty challenging (see [2]).</font></tt>
<br>
<br><tt><font size=2>Glyn</font></tt>
<br><tt><font size=2>[1] http://underlap.blogspot.com/2006/11/experimental-fix-for-sunbug-4670071.html</font></tt>
<br><tt><font size=2>[2] http://underlap.blogspot.com/2007/05/designing-module-system-interoperation.html</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>