Project Jigsaw goals and requirements

[Eric Newcomer]

Who will be the spec lead for the modularity JSR? Will it be an open process, or will the spec lead be someone from Oracle?

Eric


Sent from my iPad

On Aug 31, 2011, at 1:13 PM, mark.reinhold at oracle.com wrote:

> 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