Re: Project Jigsaw goals and requirements

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Project Jigsaw goals and requirements

Glyn Normington
For the third time of asking, what do folks think of the requirement below?

I don't mind if the requirement gets thrown out for valid technical reasons, but to not even consider it would be a shame.

Regards,
Glyn

On 22 Jun 2011, at 09:54, Glyn Normington wrote:

> This proposal didn't get a response. What do others think of the requirement?
>
> Regards,
> Glyn
>
> On 3 Jun 2011, at 12:19, Glyn Normington wrote:
>
>> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: Project Jigsaw goals and requirements

mark.reinhold
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, [hidden email]:

> 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
Reply | Threaded
Open this post in threaded view
|

Re: 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, [hidden email] 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, [hidden email]:
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Project Jigsaw goals and requirements

mark.reinhold
2011/8/31 17:48 -0700, [hidden email]:
> 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?

I will serve as the spec lead for the module-system JSR.

Whether having an Oracle spec lead is mutually exclusive with having
an "open" process depends, I suppose, upon your definition of "open".

The module-system JSR will be run in a fully transparent manner from
the start, per the guidelines presently being worked out in JSR 348.

- Mark