users@javaee-spec.java.net

[javaee-spec users] [jsr342-experts] Re: Modularization Framework/SPI

From: Jim Knutson <knutson_at_us.ibm.com>
Date: Tue, 24 Jul 2012 14:44:56 -0500

Werner Keil <werner.keil_at_gmail.com> wrote on 07/24/2012 12:27:31 PM:
> If that worked, why not.
> Let's hear from more App Server Vendors.
> Beside OSGi or Jigsaw, there are a couple of similar approaches,
> Eclipse ObjectTeams or JBoss Modules which could help as
> inspirations. Those like OSGi offer modularity already.

It's all about semantics. You can't start half way down a
modularization path without immediately getting into the semantic
meaning of module metadata and that has to start with a well
defined module environment.

What does defining a version mean in the presence of maintenance
releases? Does defining a major version change (e.g. JPA 2.0)
imply that existing app usage cannot bind to it? Is binding to
a spec version going to bind to an implementation or an
implementation agnostic API? What if you want the Hibernate
or OpenJPA version of JPA 2.0 and not just a generic JPA 2.0?
What about cases like JavaMail where the API and impl are
intimately tied together?

Basically, everything hinges on making a choice for the module
system and the meaning of that choice on the metadata.

Thanks,
Jim Knutson
WebSphere Java EE Architect