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 <[EMAIL PROTECTED]>
Reply-To: Java Community Process JSR #277 Expert List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
References:
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
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
