[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 13:45:57 -0700
From: Stanley M. Ho <Stanley.Ho at Sun.COM>
Reply-To: Java Community Process JSR #277 Expert List <JSR-277-EG at JCP.ORG>
Organization: Sun Microsystems, Inc.
To: JSR-277-EG at JCP.ORG
References:
<OF38B15AAD.C1681E9F-ON802572E5.0034F269-802572E5.0036FB6B at uk.ibm.com>
<465625C0.1050107 at sun.com> <4656FA00.7000507 at ungoverned.org>

Hi Richard,

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

That's not exactly what I was saying. JSR 277 is set out to address a
set of modularity, packaging and deployment problems that are
fundamental in the Java SE platform, e.g. classpath hell, versioning
hell, other issues related to jars and standard extensions, etc. The
solution will be used in a variety of applications and environments,
e.g. standalone applications, sandboxed applications (applets, JNLP),
etc. It will also be used along with JSR 294 for modularizing the JRE in
the future. Thus, the features and functionalities in JSR 277 must be
sufficient to address this set of problems.

One example is JRE modularization. If we need certain features in JSR
277 to make this possible, we'll create these features; leveraging
features in other module systems to do JRE modularization would be
completely missing the point. :-)

I totally agreed with you that we don't want to push all the features
from other module systems into the core. On the other hand, I don't
think we can avoid bringing some features into the core if they are
necessary to address some very fundamental or common problems in the SE
platform, and hopefully everyone will be benefited as a result.

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

The service/service-provider model has existed in the SE platform since
JDK 1.3 (as far as I recalled), and this is what the JRE has been using
internally to look up SPI implementations in various components. The JAR
file format also has support for service-providers, but it has many
problems related to versioning and others that are supposed to be
addressed by JSR 277. Since this service/service-provider model is
already used heavily with JARs in the core platform and we envision
modules will be used in many deployment scenarios where JARs are used
today, what the strawman describes is simply how this existing
service/service-provider model would fit in the world of modules.

At a minimal, I think this existing service/service-provider model
should be supported in the module system defined by JSR 277. The
strawman currently describes this service/service-provider model would
be supported in the module layer (in the hope that all module systems
can benefit from it so they don't have to keep working around the
service-provider lookup problems themselves), but I think this is still
up for debate in another thread. This is the whole point of having a
strawman in the first place. ;-)

> 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

I may have misunderstood the context behind Glyn's statement about
"ditch every JSR 277 feature that is overlapped with JSR 291". :-) But I
agreed with you completely that we should define the minimal set of
features possible to accomplish what we need to be accomplished, and I
think this is what we have been doing all along.

- Stanley