Monday, June 27, 2011

Jigsaw déjà vu

I recently questioned one of the Jigsaw requirements on the jigsaw-dev mailing list. I agree with the general direction for interoperability with OSGi, but I wanted to suggest an improvement:

Hi Mark

I'm pleased to see the explicit acknowledgement of some basic OSGi interoperation requirements in the requirements document ([1]).

I agree with David Bosschaert ([2]), that it would make sense for OSGi to support the Java SE 8 module format and, for modules which can serve equally well as OSGi bundles, I'd like to avoid dual-maintenance of module metadata and OSGi manifest. I'd like to be able to "decorate" the standard metadata.

However, the requirement "The syntax must place all extended metadata after all standard metadata, with a clear delineation between them." precludes inline decorations. The result would be duplication and clunkiness.

I propose that this requirement be changed so that standard metadata could be decorated inline (the decorations would be ignored by the Java SE module system).

What do you think?

Regards,
Glyn
[1] http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12
[2] http://osgithoughts.blogspot.com/2011/05/java-se-8-modularity-requirements.html

The response: zilch!

After a follow-up, I got a single supportive response, but that was from OSGi aficionado Peter Kriens.

I would have preferred some defence of the current requirement rather than silence. This is awfully like the days of JSRs 277 and 294. Plus ça change, plus c'est la même chose...

3 comments:

David Bosschaert said...

I agree, Glyn. I am quite disappointed at the lack of true dialog on that mailing list.

And BTW I also strongly agree with your suggestion around decorating the standard metadata!

Peter Kriens said...

You must have been in France recently? :-)

As I indicated before, it is disconcerting how the list seems to roll on without reacting to this.

David M. Lloyd said...

Agreed. I think that the fact is that in reality, this is happening inside a closed room inside of Oracle, which is very unfortunate. The best we can do is put our feedback out there and on the record, and hope that we can work with whatever actually comes out of the black box.

Projects

OSGi (130) Virgo (59) Eclipse (10) Equinox (9) dm Server (8) Felix (4) WebSphere (3) Aries (2) GlassFish (2) JBoss (1) Newton (1) WebLogic (1)