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