Disable all warnings
Rémi
----- Mail original -
De: "Stephan Herrmann" <stephan.herrm...@berlin.de>
À: jigsaw-dev@openjdk.java.net
Envoyé: Dimanche 22 Janvier 2017 15:25:57
Objet: Re: Reusing module name token `*` in -d
On 01/22/2017 02:50 PM, Remi Forax wrote:
by javac.
At least part of the problem is that we don't have a good place to write such
documentation/specification. We are working on that too.
-- Jon
On 1/22/17 8:21 AM, Stephan Herrmann wrote:
Thanks.
Is that the documentation that JLS mentions?
I was expecting s.t. that search engine
On 01/21/2017 06:52 PM, fo...@univ-mlv.fr wrote:
Robert,
How do you compile these 2 modules with Maven ?
module foo {
exports foo to bar;
}
module bar {
requires foo;
}
when compiling 'foo' javac needs to see if 'bar' exists and when compiling
'bar', javac will ask to see 'foo'.
I
inal -
De: "Robert Scholte" <rfscho...@apache.org>
À: jigsaw-dev@openjdk.java.net
Envoyé: Samedi 21 Janvier 2017 20:12:37
Objet: Re: Reusing module name token `*` in -d
On Sat, 21 Jan 2017 19:35:28 +0100, Stephan Herrmann
<stephan.herrm...@berlin.de> wrote:
On 01/21/2017 06
I found the general direction of this proposal interesting,
but from the reluctance to accept this, I start to think,
that maybe the role of multi-module compilation was overrated?
I assume that the majority of source code out there is organized
in some structure like
Project1
+
On 02/17/2017 12:19 AM, Stephen Colebourne wrote:
The simplest and most consistent option is reverse DNS everywhere.
Everyone understand it and few will object!
An alternative option would be that open source can use short names,
but companies "must" use reverse DNS. But this is far from ideal
I'm wondering what will be expected from a compiler for Java 9.
I hope this is a suitable place to ask this kind of questions.
The first thing we know: a compiler has to be able to translate
module-info.java (or whatever that file's name may be - btw: in absence of a
definite rule, is a
Alex,
I understand the motivation of not breaking existing code that uses these as
identifiers.
I just want to understand the precise rules and figure out if any established
technology
can recognize the desired language.
On 11/16/2016 10:02 PM, Alex Buckley wrote:
[...]
Make a close reading
On 11/17/2016 12:10 AM, Alex Buckley wrote:
On 11/16/2016 3:03 PM, Stephan Herrmann wrote:
On 11/16/2016 11:57 PM, Alex Buckley wrote:
On 11/16/2016 2:26 PM, Stephan Herrmann wrote:
And we may safely assume regularity of the grammar, i.e.,
the above approach will never lead to ambiguities
On 11/16/2016 10:02 PM, Alex Buckley wrote:
- If you lex 'package', then the sequence must parse as the first alternative.
- If you don't lex 'package', but rather lex 'import', then parsing is
ambiguous until you've looked ahead to lex either 'open',
'module', or a keyword that can start
On 11/16/2016 11:57 PM, Alex Buckley wrote:
On 11/16/2016 2:26 PM, Stephan Herrmann wrote:
And we may safely assume regularity of the grammar, i.e.,
the above approach will never lead to ambiguities, right?
Fictitious counter example
ModuleDeclaration:
module open Identifier
On 11/16/2016 11:35 PM, Jonathan Gibbons wrote:
On 11/16/2016 02:26 PM, Stephan Herrmann wrote:
Still no good news for tools wishing to process just a fragment of the text.
Just how small a fragment, and in how unknown a context are you worried about?
Yes, if you're wanting to locally
On 11/16/2016 11:19 PM, Jonathan Gibbons wrote:
On 11/16/2016 02:08 PM, Stephan Herrmann wrote:
On 11/16/2016 10:02 PM, Alex Buckley wrote:
- If you lex 'package', then the sequence must parse as the first alternative.
- If you don't lex 'package', but rather lex 'import', then parsing
Hi Alex,
On 11/15/2016 12:20 AM, Alex Buckley wrote:
You have a lot of questions here, mainly not about the OpenJDK implementation
of JSR 379 but rather about JSR 379 itself. I'm
working on JLS text that will be presented alongside lang-vm.html in the next
few weeks, but here are some quick
On 01/08/2017 08:13 PM, Stephan Herrmann wrote:
[...]
Lastly, with the interplay of things defined in JLS vs. observability
which is subject to the host system, I wonder if JLS will at least include
"recommendations" regarding the structure of directories and compilation
units. The
On 01/07/2017 01:37 AM, Alex Buckley wrote:
On 1/4/2017 12:44 PM, Stephan Herrmann wrote:
Given that types are identified by qualified names that
do not contain the module name, this distinction doesn't seem to be
possible per JLS.
Per 7.3, javac is associating a first other.Other type
On 01/10/2017 11:24 PM, Alex Buckley wrote:
On 1/10/2017 12:20 PM, Stephan Herrmann wrote:
Can a module export a package even if no compilation units of that package
are associated with the current module? The export might only affect types
exported from some other required module
I have started to dig through the JLS changes (2016-12-16) to figure out requirements for a Java 9 compiler without consulting
javac, but I'm having some difficulties understanding the interplay of scope, visibility, importing, accessibility and observability
at this level.
For instance, this
Hi Alex,
On 01/07/2017 01:37 AM, Alex Buckley wrote:
On 1/4/2017 12:44 PM, Stephan Herrmann wrote:
Yes, and I owe you some apologies for this. The "visibility of a declaration"
is an obscure corner of the scope rules, and I intend
to rename it. Visibility will una
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
On 06.06.2017 12:37, Stephan Herrmann wrote:
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 ineffecti
Given:
// one/p/C.java
package p;
public class C {}
// one/module-info.java
module one {}
// two/q/D.java:
package q;
import p.C;
public class D {}
// two/module-info.java
module two {}
javac only needs a --add-exports to accept the code
$ javac9 -d bin --module-source-path . --add-exports
This continues a discussion we had in January, but still isn't
fully resolved in JLS 2017-06-26:
Does the parent-sub relation of packages bear any meaning
from the JLS p.o.v.?
On 2017-01-10 Alex conceded:
"... you can consider all packages as unrelated to each other."
Still JLS 6.5.3.2 has
compile an arbitrary module-info.java and then:
$ javap module-info.class
Error: error while reading constant pool for /tmp/bin/module-info.class:
unexpected tag at #5: 19
From tweaking the Eclipse compiler it seems that javap is expecting a
CONSTANT_Utf8_info,
where according to JVMS 4.7.25
----- Mail original -
De: "Stephan Herrmann" <stephan.herrm...@berlin.de>
À: jigsaw-dev@openjdk.java.net
Envoyé: Samedi 1 Juillet 2017 17:08:20
Objet: javap cannot read module-info.class
compile an arbitrary module-info.java and then:
$ javap module-info.class
Error: error w
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
When you say "bug" do you mean
(a) the name of that automatic module should avoid any Java keyword, or
(b) Java keywords should be accepted as (part of) a module name?
Option (a) would require a change in the specification of ModuleFinder
whereas (b) currently conflicts with JLS 7.7 which
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
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
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 03.05.2017 20:55, Remi Forax wrote:
> It's context-free because a context free grammar defined its input in term of
> terminals and the theory do not say how to map a token to a terminal.
>
> Jay is right that it requires to use either some specific parser generator
> like Tatoo [1] the one
s.
I don't have a name for it.
The best description I could come up with so far is:
"restricted keywords are keywords when it helps to interpret them as keywords".
Stephan
On 04.05.2017 00:06, fo...@univ-mlv.fr wrote:
- Mail original -
De: "Stephan Herrmann" <st
Over in jpms-spec-experts I still see discussion about #CyclicDependences,
which made me wonder (admittedly late), what will be the solution for
AOP-like languages which inherently need bidirectional dependencies?
Is it correct that at runtime cycles pose no problems?
Let's assume a language
ty to work on incomplete code.
Stephan
On 18.05.2017 00:34, Remi Forax wrote:
I want to answer this before we start the meetings because i really think that
restricted keyword as i propose solve the issues Stephan raised.
- Mail original -----
De: "Stephan Herrmann" <stephan.herrm.
names matching
restricted keywords? Current restriction for modules is that they can
not have an unnamed package. Do we want to restrict package names a
module can export too?
you should use reverse DNS naming for package so no problem :)
Stephan's solution does not have this problem.
Regards,
(1) I understand the need for avoiding that new module-related
keywords conflict with existing code, where these words may be used
as identifiers. Moreover, it must be possible for a module declaration
to refer to packages or types thusly named.
However,
(2) The currently proposed "restricted
We don't need more proposals how to solve the problem.
We need agreement that we have a problem!
Stephan
On 12.06.2017 23:31, Ralph Goers wrote:
I had this same thought a week or so ago and I wouldn’t be surprised to see
someone create a framework that generates a module-info.java from
"restricted keywords" + helping automatic modules
Date: Fr 19 Mai 2017 07:27:31 CEST
From: John Rose<john.r.r...@oracle.com>
To: Stephan Herrmann<stephan.herrm...@berlin.de>
On May 18, 2017, at 1:59 AM, Stephan Herrmann <stephan.herrm...@berlin.de>
wrote:
In all posts I coul
The 2017-05-18 draft of JLS indicates that automatic modules are beyond the
scope of JLS.
I'm puzzled what that should mean for a compiler.
At face value it seems to say that compilers need not care about automatic
modules. Instead I'd expect JLS to state that the host system must be able
to
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
readabi
The 2017-05-18 update of JLS 6.5.3.2 introduces the concept of
unique visibility, but still has this unchanged sentence:
"The package name Q.Id names a package that is the member named Id
within the package named by Q."
If "the" in "the member named Id" is to be taken literally, then
the
On 23.05.2017 22:30, Alex Buckley wrote:
On 5/23/2017 12:54 PM, Stephan Herrmann wrote:
The 2017-05-18 draft of JLS indicates that automatic modules are beyond the
scope of JLS.
I'm puzzled what that should mean for a compiler.
At face value it seems to say that compilers need not care about
On 23.05.2017 22:12, Alex Buckley wrote:
On 5/23/2017 1:04 PM, Stephan Herrmann wrote:
The 2017-05-18 update of JLS 6.5.3.2 introduces the concept of
unique visibility, but still has this unchanged sentence:
"The package name Q.Id names a package that is the member named Id
w
I haven't seen any reaction to this sub-topic:
- If an automatic module would have a name containing a Java keyword,
is it OK to simply refuse handling this artifact as an automatic module?
Stephan
On 18.05.2017 10:59, Stephan Herrmann wrote:
Remi,
I see your proposal as a minimal
Inline
On 19.05.2017 15:53, fo...@univ-mlv.fr wrote:
*De: *"Stephan Herrmann" <stephan.herrm...@berlin.de>
*À: *"John Rose&quo
e this as an issue of
language design *vs.* tool implementation.
We can only make our users happy, if both aspects smoothly integrate,
Stephan
On 19.05.2017 18:51, fo...@univ-mlv.fr wrote:
- Mail original -
De: "Stephan Herrmann" <stephan.herrm...@berlin.de>
À: fo.
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
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 'r
On 30.05.2017 23:43, Alex Buckley wrote:
On 5/30/2017 2:08 PM, Jochen Theodorou wrote:
On 30.05.2017 21:42, Alex Buckley wrote:
On 5/26/2017 4:12 AM, Jochen Theodorou wrote:
On 26.05.2017 01:04, Alex Buckley wrote: [...]
The semantics of an observed JAR without module-info.class are
SOTMS says: "The unnamed module reads every other module."
I am unable to find any similar statement in any specification.
Where should I be looking?
Stephan
On 06.06.2017 23:40, Alex Buckley wrote:
On 6/6/2017 2:28 PM, Stephan Herrmann wrote:
SOTMS says: "The unnamed module reads every other module."
I am unable to find any similar statement in any specification.
Where should I be looking?
The unnamed module is never resolved, so
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
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
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
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
I just happened to search for the specification of the class file
representation of modules. I was quite surprised to find nothing in JVMS.
Then I found:
"The changes to the class-file chapter in support of module declarations
are not included in this draft of the JVMS; they will be included in
Alex,
I appreciate your answers to our questions, which give hope
that a future version - incorporating all this - will be sufficient
for defining what is Java 9 from a compiler's perspective.
The post sent by Markus explicitly refers to the specification
as it was submitted for public review,
On 06.05.2017 21:49, mark.reinh...@oracle.com wrote:
2017/5/6 9:56:12 -0700, stephan.herrm...@berlin.de:
Alex,
I appreciate your answers to our questions, which give hope
that a future version - incorporating all this - will be sufficient
for defining what is Java 9 from a compiler's
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 so
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
On 06.06.2017 18:59, Alex Buckley wrote:
A module name has the same structure as a package name, so ModuleElement has the same shape as PackageElement: each inherits
getSimpleName() from Element, and getQualifiedName() from getQualifiedName() from QualifiedNameable.
Syntactically you're right,
On 06.06.2017 19:35, David M. Lloyd wrote:
On 06/06/2017 12:14 PM, Stephan Herrmann wrote:
On 06.06.2017 18:59, Alex Buckley wrote:
A module name has the same structure as a package name, so ModuleElement has the same shape as PackageElement: each inherits
getSimpleName() from Element
On 07.11.2017 21:43, Alan Bateman wrote:
On 07/11/2017 18:56, Stephan Herrmann wrote:
I recently noticed that compilers start to ignore -classpath as soon
as module-info (.java or .class) is found during the compile.
(Incidentally, javac and Eclipse compiler agree in this).
Using a trivial
?
regards,
Stephan
On 07.11.2017 23:03, Jonathan Gibbons wrote:
On 11/07/2017 12:56 PM, Stephan Herrmann wrote:
On 07.11.2017 21:43, Alan Bateman wrote:
On 07/11/2017 18:56, Stephan Herrmann wrote:
I recently noticed that compilers start to ignore -classpath as soon
as module-info (.java
I recently noticed that compilers start to ignore -classpath as soon
as module-info (.java or .class) is found during the compile.
(Incidentally, javac and Eclipse compiler agree in this).
Using a trivial test class this works:
$ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java
This
Hi,
Given these sources:
src/mod.one/module-info.java
//---
module mod.one {
requires transitive java.sql;
}
//---
src/mod.one/p/X.java
//---
package p;
public class X {
public static java.sql.Connection getConnection() {
return null;
}
}
//---
Thanks, Alex, for your answer, and sorry for the long delay on my side.
I found the background regarding deprecation of packages quite interesting,
and agree to most of what you say.
On 03.04.2018 02:49, Alex Buckley wrote:
You're right -- the JLS does not mandate a warning when compiling code
I'm looking at how deprecation affects elements larger than types,
and it seems to me that deprecation is much weaker than it could be.
Packages: JLS & javadoc agree that @Deprecated applied to a package
has no effect. Given that @Target explicitly includes PACKAGE this
looks inconsistent to me.
On 30.03.2018 00:56, Jonathan Gibbons wrote:
On 3/29/18 3:49 PM, Stephan Herrmann wrote:
On 29.03.2018 18:02, Alan Bateman wrote:
On 29/03/2018 15:36, Stephan Herrmann wrote:
I'm looking at jdk.xml.bind/module-info.class from JDK 9.0.4.
I do find a RuntimeVisibleAnnotation attribute
Thanks, Jon, that's exactly what I was looking for.
Stephan
On 30.03.2018 01:23, Jonathan Gibbons wrote:
On 3/29/18 4:02 PM, Stephan Herrmann wrote:
On 30.03.2018 00:56, Jonathan Gibbons wrote:
On 3/29/18 3:49 PM, Stephan Herrmann wrote:
On 29.03.2018 18:02, Alan Bateman wrote:
On 29/03
On 29.03.2018 18:02, Alan Bateman wrote:
On 29/03/2018 15:36, Stephan Herrmann wrote:
I'm looking at jdk.xml.bind/module-info.class from JDK 9.0.4.
I do find a RuntimeVisibleAnnotation attribute representing
@java.lang.Deprecated(since="9", forRemoval=true)
but I don't find a
I'm looking at jdk.xml.bind/module-info.class from JDK 9.0.4.
I do find a RuntimeVisibleAnnotation attribute representing
@java.lang.Deprecated(since="9", forRemoval=true)
but I don't find a Deprecated attribute.
Is this intended? JVMS 4.7.15 neither includes nor excludes
modules, but not
Hi,
This has been discussed on StackOverflow in threads like
https://stackoverflow.com/q/51094274/4611488
The question can be simplified like this:
//---
import javax.xml.transform.Transformer;
public class Test {
Transformer transformer;
}
//---
Which of the following compiler
and the Eclipse bug that javac does the wrong thing, but no-one says what it is. Are you
saying that javac (which version?) compiles Test.java in the second and third invocations?
Alex
On 12/18/2018 3:21 PM, Stephan Herrmann wrote:
Thanks for confirming!
Stephan
On 18.12.18 21:38, Alex Buckley wrote
Thanks for confirming!
Stephan
On 18.12.18 21:38, Alex Buckley wrote:
On 12/18/2018 11:04 AM, Stephan Herrmann wrote:
This has been discussed on StackOverflow in threads like
https://stackoverflow.com/q/51094274/4611488
The question can be simplified like this:
//---
import
f that is an intended solution, shouldn't it
be much more advertised? Note that no individual library owner will see any
problem, the problem only arises when trying to combine several unfortunate
libraries.
Stephan
On 26.08.19 10:13, Alan Bateman wrote:
On 24/08/2019 21:11, Stephan Herrmann wrote
Hi,
back then when working on our compiler I didn't pay much attention to non-Java
resources, as JLS doesn't make any mention of them.
Recently, however, we found that plain text files in a modular jar can well
cause the VM to refuse starting, complaining:
Much clearer, still a few comments.
On 27.08.19 09:05, Alan Bateman wrote:
- What should happen when (2) declares a set of packages that differs from
what scanning would result in? Can (2), e.g., be used to hide a package?
The ModulePackages attribute would win in that case, at least in the JDK
78 matches
Mail list logo
