Comparison of JSR 277 and JSR 291 features
A number of people have expressed an interest in the similaries and differences between these JSRs, so this post compares the features of the Early Draft Review specification of JSR 277 and the Final Specification of JSR 291, although you'll have to read the specifications to understand the differences in detail.
This a functional comparison and doesn't attempt to draw out advantages and disadvantages of various features or other aspects of the JSRs. For ease of comparison, I've referred to JSR 291 bundles as modules.
Equivalent features:
- Module name
- Module version
- Module attributes
- Module import
- Module re-export
- Version range
- Optional import
- Executable modules
- One class loader per module
- Platform dependencies
- Modules may contain classes, native libraries, resources, and extensible metadata
- Module signing
- JAR distribution format
- Reflective API
- Programmatic import policy vs declarative import constraints (details)
- Class space consistency: validation vs constraint solving
- Default export granularity: class vs package (details)
- Module-superpackage relationship (details)
- Standard repository:
- organised hierarchically with parental delegation
- multiple standard implementations for local or networked deployment
- support for plugging in 3rd party repository implementations
- JAM distribution format
- Import override policy
- Part of the Java SE platform (planned for Java 7)
- Dynamic lifecycle support both for module lifecycle and service lifecycle
- Service support (above and beyond the basic service provider support in Java SE)
- Package import
- Dynamic package import
- Package attributes
- Mandatory attributes
- Split package support
- Module classpath
- Fragment modules
- Extension modules
- Pure Java implemented on top of Java SE
- Compatible with Java ME (JSR 232)
12 comments:
You forgot:
* Number of years design and deployment: 0 vs 7
* Number of companies using the technology: 0 vs many
* Number of companies wishing to NIH: 1 vs 0
:-9
Alex
Hi Alex. I was trying to create light rather than heat.
Build a man a fire and he'll be warm for a day. Set a man on fire and he'll be warm for the rest of his life -- Terry Pratchett :-)
There's enough arson about already.
"Default export granularity: class vs package"
should that be "module vs package"?
No, it really is "class vs package", but I can see why this might be confusing, so I wrote a clarification.
Don't mind me. I'm just arson about.
Glyn,
I believe you are missing a few items in the "Unique to JSR 277" section:
. integration with modularity at the Java language and VM level (through JSR 294)
. comprehensive reflective APIs
. hierarchical repository structure with delegation
. multiple standard repository implementations, suitable for both local and networked deployment (Local and URL repository)
. extensible architecture allowing for pluggable 3rd party repository implementations
. module system framework that allows other module system implementations to be plugged in
That list is based on the EDR. More recent discussion in the JSR 277 EG is also yielding other features such as integration with java.util.ResourceBundle and java.util.ServiceLoader, among other things.
Andreas.
Thanks Andreas.
>. integration with modularity at
> the Java language and VM level
> (through JSR 294)
Wouldn't JSR 291 benefit equally from JSR 294's language and VM support for modules? A JSR 291 module would simply have to wrap its classes in one (or more) superpackages.
Or was your point simply that JSR 277 attaches its metadata to superpackages?
>. comprehensive reflective APIs
This seems more like a common feature. JSR 291's Bundle interface enables a module's metadata, state, and other properties to be accessed reflectively.
>. hierarchical repository structure
> with delegation
>
>. multiple standard repository
> implementations, suitable for both
> local and networked deployment
> (Local and URL repository)
>
>. extensible architecture allowing
> for pluggable 3rd party repository
> implementations
These are sub-features of the repository feature which was already listed as unique to JSR 277, but I've added them as sub-bullets for clarity.
>. module system framework that allows
> other module system implementations
> to be plugged in
The EDR doesn't actually allow this, although this is listed as an Expert Group work item in section C.7.
In particular, the EDR declares Module and ModuleDefinition as 'final' classes so there's no way to subclass them.
Glyn,
see comments below.
>. integration with modularity at
> the Java language and VM level
> (through JSR 294)
Wouldn't JSR 291 benefit equally from JSR 294's language and VM support for modules? A JSR 291 module would simply have to wrap its classes in one (or more) superpackages.
JSR 291 will be able to utilize superpackages. However, the information in the superpackage (name, members, exports, metadata) has no meaning to JSR 291 as it stands today and needs to be duplicated in the OSGi manifest.
In other words, JSR 291 is agnostic of superpackages and not integrated with them, similar to other existing deployment mechanisms such as a JAR + URLClassLoader.
>. comprehensive reflective APIs
This seems more like a common feature. JSR 291's Bundle interface enables a module's metadata, state, and other properties to be accessed reflectively.
JSR 291 has a runtime API, but as far as I am aware it does not reflect all OSGi concepts. For example dependencies: which actual bundles/package was my bundle wired up with at runtime? Having a comprehensive reflective API for all features is important to enable innovation in higher level libraries as well as for diagnostics.
>. module system framework that allows
> other module system implementations
> to be plugged in
The EDR doesn't actually allow this, although this is listed as an Expert Group work item in section C.7.
The EDR is also pluggable, it just uses a delegation model instead of direct subclassing. See ModuleProvider and ModuleDefinitionProvider in the spi package.
Andreas.
Fair point about integration with vs agnosticism towards JSR 294. I'll probably write this up rather than try to cram it in a couple of bullets. Meanwhile your comment is here for the record.
I need to check the precise reflective capabilities of JSR 291 to compare it accurately against the JSR 277 reflective API.
The provider SPIs in the EDR are really nothing more than placeholders. IIRC they aren't referred to in the rest of the spec.
I checked and found JSR 291 also provides a comprehensive reflective API in the form of the PackageAdmin service in addition to the Bundle interface mentioned above.
In particular, PackageAdmin lets you query package and module dependencies, their names and versions, as well as whether these dependencies are 'pending removal', which means whether they are satisfied by a module which has been updated or uninstalled.
So I've added reflective API to the list of equivalent features (omitting the adjective 'comprehensive' to avoid marketing overtones).
Post a Comment