More jigsaw spec clarifications

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

More jigsaw spec clarifications

Jonathan Gibbons
Thank you for the preceding round of discussion and spec-updates.

The compile-time errors are all assertions that can be evaluated by
examining an individual module declaration. Do you envisage specifying
any compile-time errors arising from examining the set of observable
module declarations.   For example, the restriction on duplicate views
within a module declaration could be extended to be a restriction on
duplicate observable views.  And, what about different modules trying to
export the same package?

Separately, in the restrictions on the class names for entry points and
service implementations, is it expected that the class names must be
declared in the module declaring the entry point or service, or can the
class names be found in the (re-)exports of any of the required modules?

-- Jon
Reply | Threaded
Open this post in threaded view
|

Re: More jigsaw spec clarifications

Alan Bateman
On 21/01/2012 01:39, Jonathan Gibbons wrote:
>
> Separately, in the restrictions on the class names for entry points
> and service implementations, is it expected that the class names must
> be declared in the module declaring the entry point or service, or can
> the class names be found in the (re-)exports of any of the required
> modules?
I don't think this make a differences for services, unless permits is used.

-Alan.
Reply | Threaded
Open this post in threaded view
|

Re: More jigsaw spec clarifications

Alex Buckley
In reply to this post by Jonathan Gibbons
On 1/20/2012 5:39 PM, Jonathan Gibbons wrote:
> Do you envisage specifying any compile-time errors arising from
> examining the set of observable module declarations. For example, the
> restriction on duplicate views within a module declaration could be
> extended to be a restriction on duplicate observable views. And, what
> about different modules trying to export the same package?

It would be nice if the module system was responsible for detecting
inter-declaration errors while the compiler sticks to intra-declaration
errors.

The module system already has the logic for finding different modules
(within a dependency graph) exporting the same package, so why should a
compiler duplicate it for source-form declarations? Perhaps this comes
down to the interface between compiler and module system. Will be a
sketch of how javac's interaction with the classpath is modified to work
with Jigsaw?

Alex
Reply | Threaded
Open this post in threaded view
|

Re: More jigsaw spec clarifications

Jonathan Gibbons
On 01/23/2012 11:10 AM, Alex Buckley wrote:

> It would be nice if the module system was responsible for detecting
> inter-declaration errors while the compiler sticks to
> intra-declaration errors.
>
> The module system already has the logic for finding different modules
> (within a dependency graph) exporting the same package, so why should
> a compiler duplicate it for source-form declarations? Perhaps this
> comes down to the interface between compiler and module system. Will
> be a sketch of how javac's interaction with the classpath is modified
> to work with Jigsaw?

It would be nice if the module system had more than one error message:
"Cannot resolve".  I know it is on the list to fix that, but I was
trying to work on the common and easy cases.

Anyway, you changed the subject to one of implementation detail.  I was
asking about the spec :-)  Where should I look for specification details
about the restrictions on duplicate names in the module graph.

-- Jon
Reply | Threaded
Open this post in threaded view
|

Re: More jigsaw spec clarifications

Alex Buckley
On 1/23/2012 11:28 AM, Jonathan Gibbons wrote:
> Anyway, you changed the subject to one of implementation detail. I was
> asking about the spec :-) Where should I look for specification details
> about the restrictions on duplicate names in the module graph.

Doesn't the "big picture" draft on the Jigsaw project page have
assertions sprinkled throughout? Or the javadoc for java.lang.module or
its org.openjdk.jigsaw counterpart?

Alex
Reply | Threaded
Open this post in threaded view
|

Re: More jigsaw spec clarifications

Jonathan Gibbons
On 01/23/2012 11:40 AM, Alex Buckley wrote:

> On 1/23/2012 11:28 AM, Jonathan Gibbons wrote:
>> Anyway, you changed the subject to one of implementation detail. I was
>> asking about the spec :-) Where should I look for specification details
>> about the restrictions on duplicate names in the module graph.
>
> Doesn't the "big picture" draft on the Jigsaw project page have
> assertions sprinkled throughout? Or the javadoc for java.lang.module
> or its org.openjdk.jigsaw counterpart?
>
> Alex

"Big picture" is not intended to be a spec is it?     I'll check the
javadocs you mention.

Presumably, "it is a compile-time error if the set of modules cannot be
resolved by ..."  By whom? The host system?  The system module
resolver?  The Jigsaw module resolver?

-- Jon
Reply | Threaded
Open this post in threaded view
|

Re: More jigsaw spec clarifications

Alex Buckley
On 1/23/2012 11:55 AM, Jonathan Gibbons wrote:
> Presumably, "it is a compile-time error if the set of modules cannot be
> resolved by ..." By whom? The host system? The system module resolver?
> The Jigsaw module resolver?

Given that the language in SE 8 can assume the presence of a module
system, we could distinguish in the JLS between a compiler and a
resolver. I don't really expect it will be useful to do so, however. But
perhaps experience with how the R.I. compiler talks to the R.I. module
system will inform this.

Alex
Reply | Threaded
Open this post in threaded view
|

Re: More jigsaw spec clarifications

Jonathan Gibbons
On 01/23/2012 12:00 PM, Alex Buckley wrote:

> On 1/23/2012 11:55 AM, Jonathan Gibbons wrote:
>> Presumably, "it is a compile-time error if the set of modules cannot be
>> resolved by ..." By whom? The host system? The system module resolver?
>> The Jigsaw module resolver?
>
> Given that the language in SE 8 can assume the presence of a module
> system, we could distinguish in the JLS between a compiler and a
> resolver. I don't really expect it will be useful to do so, however.
> But perhaps experience with how the R.I. compiler talks to the R.I.
> module system will inform this.
>
> Alex

Currently, javac calls org.openjdk.jigsaw.Configurator.configurePaths
passing an impl of org.openjdk.jigsaw.Catalog containing the module info
known to javac.

-- Jon