Bryan Atsatt <[EMAIL PROTECTED]> wrote on 23/05/2007 20:52:47: > Stanley M. Ho wrote: > >> I think we need to think hard about this issue. The OSGi model of import > >> by *package name* decouples the importer from any explicit binding to a > >> bundle/module name. Refactoring under that model is *much* cleaner, and > >> far more natural. As is the usage model. After all, Foo.java import > >> statements contain package/class names, *not* module names. Programmers > >> think in terms of classes and packages. > >> > >> Peter makes this point pretty strongly, and I have to say I agree > >> wholeheartedly: > >> > >> http://www.aqute.biz/Blog/2006-04-29 > > > > I agreed that in some situations it is much better to have dependency > > that is loosely coupled. You may want to check out the service-providers > > strawman that I just sent out, and it deals with the exact issue around > > API vs implementation. > > That's great, but sort of beside the point :^). > > I am specifically referring to the syntax and semantics of "import" > declarations. At the moment, 277 supports only the "Reguire Bundle" > style semantics defined by OSGi. This model is is inherently > tightly-coupled, and its use is greatly discouraged in the OSGi world. > It was not even present in the initial releases. > > I strongly believe that it would be a huge mistake for 277 to support > only this model. If we want to simplify things and support only one > model, then we should choose import by package name/version, *not* > import by module name/version.
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. 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. 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]). Glyn [1] http://underlap.blogspot.com/2006/11/experimental-fix-for-sunbug-4670071.html [2] http://underlap.blogspot.com/2007/05/designing-module-system-interoperation.html Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
