Comments on Mind the gap: Comparison of JSR 277 and JSR 291 features

I checked and found JSR 291 also provides a compre...

2007-06-22T09:45:00.000+01:00

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

Fair point about integration with vs agnosticism t...

2007-06-21T20:54:00.000+01:00

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.

Glyn,see comments below.>. integration with modula...

2007-06-21T20:15:00.000+01:00

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.

Thanks Andreas.>. integration with modularity at> ...

2007-06-21T13:45:00.000+01:00

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,I believe you are missing a few items in the ...

2007-06-21T03:39:00.000+01:00

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.

Don't mind me. I'm just arson about.

2007-06-20T16:34:00.000+01:00

Don't mind me. I'm just arson about.

No, it really is "class vs package", but I can see...

2007-06-20T13:59:00.000+01:00

No, it really is "class vs package", but I can see why this might be confusing, so I wrote a clarification.

"Default export granularity: class vs package"shou...

2007-06-20T11:20:00.000+01:00

"Default export granularity: class vs package"

should that be "module vs package"?

There's enough arson about already.

2007-06-19T07:02:00.000+01:00

There's enough arson about already.

Build a man a fire and he'll be warm for a day. Se...

2007-06-18T22:55:00.000+01:00

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 :-)

Hi Alex. I was trying to create light rather than ...

2007-06-18T16:47:00.000+01:00

Hi Alex. I was trying to create light rather than heat.

You forgot:* Number of years design and deployment...

2007-06-18T13:01:00.000+01:00

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