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

[Stanley M. Ho]

Hi Richard,

Richard S. Hall wrote:
> Stanley M. Ho wrote:
>>
>> 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.

Right. Let me reiterate what I really meant. I think whether a feature
is supported by JSR 277 should not be determined primarily by whether
other module systems have already supported it. Rather, it should be
determined by whether the feature is required to address the problems we
are set out to solve (see my other email, I think we're on the same page
here). In case if other module systems already support the feature, this
is still great so we can learn from their experience to make sure we do
the right thing.

> 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.

I have no doubt that the import package model has its own strength over
other models. My own argument against adding the import package support
is that the "import module" model is very simple to understand and is
already sufficient for the set of problems we want to address. I don't
think the added values of the import package model on top of what the
import module model already provides would justify the technical
complexity (along your lines) and developers' confusion (two
related-but-yet-different import models to choose).

Anyway, it seems the EG consensus so far is to not add import package
support. If any EG member disagrees, please speak up.

>> 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

Richard, It is unclear to me what you meant by feature creep in the core
because everything in the specification is essentially required to
address the problems this JSR is set out to solve. We can argue that
some features should not be in the base layer API but in the module
system defined by JSR 277 instead or vice versa, but they still belong
to the overall JSR 277 specification.

To recap what we have been discussing, I think our general consensus is
to define a module system in JSR 277 that would address all the problems
this JSR is set out to solve, as well as to provide a high level
framework for different module systems (including the module system
defined by JSR 277) to layer on top for interoperation. We only
described the former in the EDR, but the latter should become more
evident in the next revision of the JSR 277 specification.

- Stanley