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

[Stanley M. Ho]

This is a 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:00:16 -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>
<465625C0.1050107 at sun.com>

Stanley M. Ho wrote:
> Hi Glyn,
>
> Glyn Normington wrote:
>> ...
>> 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
>
> As we discussed before, the charter of JSR 277 is to develop a solution
> for the next generation Java SE platform to address the problems as
> described in the original JSR submission. What we want to provide in JSR
> 277 (and this EG also agreed) is first-class modularity, packaging, and
> deployment support in the SE platform, with integration with language/VM
> (through JSR 294), classes libraries and tools. This is the problem we
> are solving, and we must provide all the features required to solve this
> problem. Whether a feature already exists in other module systems is
> orthogonal to whether it should be supported in JSR 277. That said, we
> still want to learn from the experience of these existing systems as
> much as possible, so we can design JSR 277 in the best possible way.

Are you really saying that 277 is mandated to create everything from
scratch? If so, I wasn't aware that this was mandated and it seems
somewhat odd to me, especially if there are possibilities to incorporate
or leverage existing and proven solutions.

This type of thinking seems like it will over time force us to push all
of the features from other modules systems, such as the OSGi framework,
into the core platform.

The service/service-provider interop strawman is another step in the
direction of pulling more and more into the core. While the strawman in
and of itself sounds reasonable, it is proposing modifications to the
module layer to introduce service-related concepts (e.g.,
ModuleDefinition.getServices() and
ModuleDefinitions.getServiceProviders()), which seem woefully out of
place to me. I would expect that service interoperability should be
implementable completely on top of the module layer, without pushing
service concepts down into the module layer. As an aside, I was slightly
humored by parts of the strawman that implicitly describe what amounts
to an OSGi service registry dealing with the same issues of service
selection and wiring in the face of multiple providers and multiple
versions...

Since what goes into the core SE platform is going to stick around for a
while and evolve very slowly, it seems to make the most sense to define
the minimal set of features possible to accomplish what needs to be
accomplished to provide core modularity support in the Java platform.
Adding more fanciful features on top of this minimal core should be left
to the OSGi frameworks and NetBeans frameworks of the world, which are
able to evolve more rapidly on top of the core. Trying to do too much in
the core is a recipe for disaster since we all know that there is no
going backwards once it is released, whereas focusing on the smallest
set of features necessary gives us a better chance at doing it right the
first time. I think this is the point that Glyn is getting at too...

-> richard

>
> In terms of the relationship between JSR 277 and JSR 291, I think we all
> agreed in the EG that JSR 277 will provide the necessary framework for
> interoperation with other module systems, especially with JSR 291/OSGi.
>
> Following up the original email about import package, I don't think we
> should support it in JSR 277 for a different reason, and I will reply in
> another email.
>
> - Stanley