Let me clarify. It is my assumption that 277 will provide both an
API/framework *and* a specific ModuleSystem implementation. And that
OSGi will be able to supply another ModuleSystem implementation:
277 API/Framework
/ \
/ \
277ModuleSystem OSGiModuleSystem
Therefore, the API's must *support* "import package", or it will not be
usable by the OSGiModuleSystem.
I agree that the 277ModuleSystem implementation does not need to support
"import package" semantics. Which means that the 277 APIs must support
*both* semantics.
Otherwise, OSGi will not be able to operate as a first-class citizen in
the 277 world.
And, if 294 adds support for "import", it should at least do the natural
thing of "import package". And it should also support "import module",
but supporting both at the language level may be awkward.
// Bryan
Glyn Normington wrote:
*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/
