Project Jigsaw goals and requirements

[mark.reinhold at oracle.com]

Apologies for the delayed reply.  Unfortunately I've had limited time to
devote to the modularity topic over the past couple of months.  Between
getting JDK 7 out the door, taking some much-needed vacation time, and
tending to various non-technical tasks at the request of my management
it's been an unexpectedly busy summer.  I'm in the process of ramping
back up on modularity now, however, and I expect to be more fully
engaged going forward.

2011/6/3 3:19 -0700, gnormington at vmware.com:
> 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?

Like all other design issues this one will, ultimately, be decided by
the EG of the upcoming module-system JSR, which I expect to submit some
time in October.  What you see in the Jigsaw code right now is just a
prototype.

For now, my own view on this is that we need to find the right balance
between readability and extensibility.  It's critical that the standard
metadata be easy for every developer to read.  In-line decorations tend
to reduce readability, especially when their semantics are non-standard
and module-system-dependent.  Placing extended metadata at the end of a
module declaration allows it to be maintained along with the standard
metadata but in a way that doesn't harm readability.

To put it another way, should the burden of "clunkiness" be borne by all
developers, or just by those who need to deal with extended metadata?

- Mark