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

[Stanley M. Ho]

This is another repost to sync up the EG observer mailing list.

- Stanley

-------- Original Message --------
Subject: Re: Relationship to JSR 291 [was: Re: Bryan's comments]
Date: Fri, 25 May 2007 11:01:03 -0400
From: Richard S. Hall <heavy at UNGOVERNED.ORG>
Reply-To: Java Community Process JSR #277 Expert List <JSR-277-EG at JCP.ORG>
To: JSR-277-EG at JCP.ORG
References:
<OF38B15AAD.C1681E9F-ON802572E5.0034F269-802572E5.0036FB6B at uk.ibm.com>
<4655DD63.7020900 at oracle.com> <465632F8.3080900 at sun.com>

Stanley M. Ho wrote:
> Hi Bryan,
>
> Bryan Atsatt wrote:
>> 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
>
> Right. There are also other module systems that can be plugged into this
> framework, e.g. NetBeans.
>
>> 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
>
> I think we all agreed that the module system defined by JSR 277 does not
> need to support import package. As far as I am aware (correct me if I'm
> wrong), all the existing systems support import at the module level, and
> OSGi is the only one that supports import at the package level. Thus,
> import by package should be a feature specific to the OSGi specific
> module system implementation (e.g. OSGiModuleDefinition), and I don't
> think it is necessary to push it into the base classes in JSR 277.

Well, I must at least say that this is flawed logic at best. The fact
that only the OSGi framework supports importing packages does not say
anything about whether or not it should be supported by 277 or not.
There any many valid arguments why the import package model is better
due to the fact the is declares "what" is needed, not "who" contains
what is needed.

Using "who" instead of "what" generally leads to terrible dependency
fanout due to coarse-grained module definitions and brittleness. I am
fairly certain that I could conjure up some people who could tell you
stories about the horrors of the brittleness of the module dependency
approach when trying to re-use modules for different purposes. However,
I guess this is beside the point...

I think the real argument that should be made for not necessarily
including import package support is along the lines of what I was saying
in my other message, which is that we should keep 277 as simple as possible.

> This doesn't mean supporting the notion of import by package is
> impossible. What OSGi will expose from its repository is simply module
> definitions, and module definition is basically an abstraction.
> Therefore, it should be possible to treat an OSGi bundle as a module
> definition, as well as to treat each exported package in an OSGi bundle
> a module definition as well. The dependency supported in JSR 277 is
> import-by-module. In the JSR 277 module system, this is mapped to
> import-by-superpackage. In the OSGi module system, this can be mapped to
> import-by-OSGi-bundle or import-by-package. If other module systems want
> to support different import granularity or if OSGi evolves to add new
> import granularity in the future, this model should still work.
>
> Honestly, interoperability between multiple module systems with "import
> module" alone is already a hard enough problem for us to solve. I am
> concerned that we're making this problem towards insolvable if we keep
> adding complexity. ;)

Agreed, but I think part of the reason that there is an urge to push
such features into the core is because there is already feature creep in
the core that gives people the impression that we are redefining OSGi
modularity, NetBeans modularity, etc. Thus, everyone wants to make sure
their pet feature is added. If 277 could make a stand and declare that
it is at a layer beneath all of that (and live up to that declaration),
then there would likely be less push down.

-> richard