From JLS 9.6.4.5:
"For other kinds of warnings, compiler vendors should document the strings they
support
for @SuppressWarnings. Vendors are encouraged to cooperate to ensure that the
same
names work across multiple compilers."
Any suggestions, how we can engage in such cooperation?
In particu
On 06.06.2017 11:03, Alan Bateman wrote:
On 06/06/2017 09:40, Stephan Herrmann wrote:
This was viewed from the JLS p.o.v. But "read by M" is still not well-defined.
All we see in the documentation of the referenced method is:
"a readability graph is computed"
With some further searching, w
I didn't see an answer to this question:
On 30.04.2017 23:45, Stephan Herrmann wrote:
On 30.04.2017 17:47, Alan Bateman wrote:
On 30/04/2017 12:10, Stephan Herrmann wrote:
:
Java 9 could make "API leaks" either illegal or ineffective and thus rule out
an entire category of ill-formed progra
On 06/06/2017 09:40, Stephan Herrmann wrote:
This was viewed from the JLS p.o.v. But "read by M" is still not
well-defined.
All we see in the documentation of the referenced method is:
"a readability graph is computed"
With some further searching, we find "readability graph" explained in
On 06.06.2017 10:15, Stephan Herrmann wrote:
A quick editorial comment:
On 29.04.2017 01:25, Alex Buckley wrote:
> [...] I have changed 7.3 to state:
>
> "The host system must use the Java Platform Module System (as if by
execution of the 'resolve' method of
> java.lang.module.Configuration
A quick editorial comment:
On 29.04.2017 01:25, Alex Buckley wrote:
> [...] I have changed 7.3 to state:
>
> "The host system must use the Java Platform Module System (as if by execution
of the 'resolve' method of
> java.lang.module.Configuration) to determine which modules are read by M
(§7.7.
On 01.05.2017 20:47, Alex Buckley wrote:
On 4/30/2017 3:25 AM, Stephan Herrmann wrote:
For the question at hand, this is what we learn from that improved
reference:
"A readability graph is constructed"
Now we only need a link to the specification that *defines* what is a
readability graph an
rrmann"
À: jigsaw-dev@openjdk.java.net, "Remi Forax" , "Alex Buckley"
Cc: "Brian Goetz" , "Dan Smith"
Envoyé: Mercredi 3 Mai 2017 23:31:14
Objet: Re: Java Platform Module System
On 03.05.2017 20:55, Remi Forax wrote:
It's context-free because a
- Mail original -
> De: "Stephan Herrmann"
> À: jigsaw-dev@openjdk.java.net, "Remi Forax" , "Alex
> Buckley"
> Cc: "Brian Goetz" , "Dan Smith"
>
> Envoyé: Mercredi 3 Mai 2017 23:31:14
> Objet: Re: Java Platform M
quot;
, "Brian Goetz"
Cc: jigsaw-dev@openjdk.java.net
Envoyé: Mercredi 3 Mai 2017 19:46:54
Objet: Re: Java Platform Module System
On 5/2/2017 3:39 PM, Alex Buckley wrote:
On 5/2/2017 7:07 AM, Jayaprakash Arthanareeswaran wrote:
Chapter 2 in [1] describes context-free grammars. The add
l original -
> De: "Alex Buckley"
> À: "Jayaprakash Arthanareeswaran" , "Dan Smith"
> , "Brian Goetz"
>
> Cc: jigsaw-dev@openjdk.java.net
> Envoyé: Mercredi 3 Mai 2017 19:46:54
> Objet: Re: Java Platform Module System
> On
On 5/2/2017 3:39 PM, Alex Buckley wrote:
On 5/2/2017 7:07 AM, Jayaprakash Arthanareeswaran wrote:
Chapter 2 in [1] describes context-free grammars. The addition to "3.9
Keywords" defines "restricted keywords", which prevent the grammar for
ModuleDeclaration from being context-free. This prevents
On 5/2/2017 7:07 AM, Jayaprakash Arthanareeswaran wrote:
Chapter 2 in [1] describes context-free grammars. The addition to "3.9
Keywords" defines "restricted keywords", which prevent the grammar for
ModuleDeclaration from being context-free. This prevents compilers from
using common parser genera
On 5/2/2017 5:13 AM, Stephan Herrmann wrote:
Thanks, Alex, for promising improvements in various places of the spec.
Re: Multiple packages with the same name can be "visible" (helpful
terminology for program analysis) but exactly one of these packages must
be identified as the meaning of the
/jigsaw/spec/java-se-9-jls-pr-diffs.pdf>
(2017-02-22)
- Original message -
From: Stephan Herrmann
Sent by: "jigsaw-dev"
To: Alex Buckley , jigsaw-dev@openjdk.java.net
Cc:
Subject: Re: Java Platform Module System
Date: Tue, May 2, 2017 5:43 PM
Thanks, Alex, for promising impr
Thanks, Alex, for promising improvements in various places of the spec.
I recall several threads on this list ending in you saying "still being
clarified" [1][2]. Are those issues settled by now and just need to be
penned down? Otherwise it would be very helpful just to see the list of
open quest
On 5/1/2017 1:48 PM, Stephan Herrmann wrote:
On 01.05.2017 22:17, Alex Buckley wrote:
- Another reference links "automatic modules" into JLS and will
probably
link to ModuleFinder.of(Path...), right?
This text is also an informative note. Automatic modules are
discovered through ModuleFinde
On 01.05.2017 22:17, Alex Buckley wrote:
- Another reference links "automatic modules" into JLS and will probably
link to ModuleFinder.of(Path...), right?
This text is also an informative note. Automatic modules are
discovered through ModuleFinder.of, sure, and they appear in other
places in
On 5/1/2017 12:40 PM, Stephan Herrmann wrote:
Asked differently: when it says
"Generally, the rules of the Java programming language are
more interested in dependences than dependencies."
which are the aspects where the rules of the Java programming language
*are* interested in d
On 5/1/2017 12:23 PM, Stephan Herrmann wrote:
Meanwhile I've come to the interpretation that the main weakness of JLS
concerns
handling of same-named packages in different modules.
Trouble seems to start at a difference between 6.5.5.2 and 6.5.3.1/2:
To identify a type, that type must be accessi
On 4/30/2017 4:10 AM, Stephan Herrmann wrote:
No. (B) may be true for your example, but it is not for the following
(which is similar to examples we had in our January thread):
//-- M/module-info.java
module M { exports pm; }
//-- M/impl/Other.java
package impl;
public class Other { }
//-- M/p
On 01.05.2017 20:47, Alex Buckley wrote:
Yes, the API spec for java.lang.module will be updated to define the
readability relation.
thanks.
But instead of waiting for that, I
recommend you watch https://youtu.be/Vxfd3ehdAZc?t=18m15s because readability
has been stable for a long time.
I t
On 29.04.2017 01:25, Alex Buckley wrote:
On 4/27/2017 12:38 PM, Stephan Herrmann wrote:
Let me add a friendly reminder, that we are still waiting for a
specification that unambiguously tells us which module system to implement.
For illustration:
(A) Is JPMS a module system that keeps the semant
On 4/30/2017 3:25 AM, Stephan Herrmann wrote:
For the question at hand, this is what we learn from that improved
reference:
"A readability graph is constructed"
Now we only need a link to the specification that *defines* what is a
readability graph and what is the meaning of "m1 reads m2".
I
On 30.04.2017 17:47, Alan Bateman wrote:
On 30/04/2017 12:10, Stephan Herrmann wrote:
:
Java 9 could make "API leaks" either illegal or ineffective and thus rule out
an entire category of ill-formed programs, which to-date must unfortunately
be accepted by module-unaware compilers:
(A) Java
On 30/04/2017 12:10, Stephan Herrmann wrote:
:
Java 9 could make "API leaks" either illegal or ineffective and thus
rule out
an entire category of ill-formed programs, which to-date must
unfortunately
be accepted by module-unaware compilers:
(A) Java 9 has the opportunity to say that the
On 29.04.2017 01:25, Alex Buckley wrote:
On 4/27/2017 12:38 PM, Stephan Herrmann wrote:
For illustration:
(A) Is JPMS a module system that keeps the semantics of qualified names as
they are in Java 8 and only superimposes encapsulation boundaries?
(i.e., each type is globally uniquely identifie
On 29.04.2017 01:25, Alex Buckley wrote:
On 4/27/2017 12:38 PM, Stephan Herrmann wrote:
Got it. Since now JLS is no longer self-contained it would tremendously
help if we could get a list of which parts of the API specification are
expected to be considered at compile time. I understand that we
On 4/27/2017 12:38 PM, Stephan Herrmann wrote:
On 25.04.2017 19:02, Alex Buckley wrote:
JPMS semantics (notably, dependency resolution) are defined by the API
specification (not the implementation) of
java.lang.module.Configuration and friends. JLS references to JPMS are
references to this Java
On 25.04.2017 19:02, Alex Buckley wrote:
On 4/25/2017 1:20 AM, Stephan Herrmann wrote:
On 25.04.2017 03:50, Alex Buckley wrote:
Dependency resolution in JPMS is accomplished by the static 'resolve'
method of java.lang.module.Configuration.
Interesting.
Are you saying the semantics of JPMS dep
On 4/25/2017 1:20 AM, Stephan Herrmann wrote:
On 25.04.2017 03:50, Alex Buckley wrote:
Dependency resolution in JPMS is accomplished by the static 'resolve'
method of java.lang.module.Configuration.
Interesting.
Are you saying the semantics of JPMS depends on the implementation
of one or more
On 25.04.2017 03:50, Alex Buckley wrote:
On 4/24/2017 5:22 PM, Stephan Herrmann wrote:
Obviously, defining JPMS is not done in index.html itself but delegated
to individual documents.
One of the linked documents is a version of JLS with changes on behalf
of JSR 376.
Jay's question was triggere
On 4/24/2017 5:22 PM, Stephan Herrmann wrote:
Obviously, defining JPMS is not done in index.html itself but delegated
to individual documents.
One of the linked documents is a version of JLS with changes on behalf
of JSR 376.
Jay's question was triggered by the observation that this exact versi
On 24.04.2017 18:18, mark.reinh...@oracle.com wrote:
2017/4/24 9:14:31 -0700, ja...@outlook.in:
The JLS makes references to the "Java Platform Module System" in
several places but we are not sure where this is specified. The
Eclipse JDT team has been making do with whatever informal documents
we
2017/4/24 9:14:31 -0700, ja...@outlook.in:
> The JLS makes references to the "Java Platform Module System" in
> several places but we are not sure where this is specified. The
> Eclipse JDT team has been making do with whatever informal documents
> we can get our hands on such as "State of the Modu
36 matches
Mail list logo
