Relationship to JSR 291 [was: Re: Bryan's comments]

[Glyn Normington]

Bryan Atsatt <bryan.atsatt at ORACLE.COM> 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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jsr277-eg-observer/attachments/20070524/33d240bc/attachment.html