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
the problem. If 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, Steph
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:
java.lang.LayerInstantiationExcept
d 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
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
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 invocation
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;
}
}
//---
src/mod.t
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.
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
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 attr
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'
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 gene
?
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 or
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
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 d
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 o
ion.
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
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 th
Rémi
- Mail original -
De: "Stephan Herrmann"
À: 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 while reading constant pool for
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
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 annotat
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
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 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, and
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 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 categor
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
specifie
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 '
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 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
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
withi
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 speci
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 disco
Finally, please don't take 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"
À: fo...@univ
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 mi
Inline
On 19.05.2017 15:53, fo...@univ-mlv.fr wrote:
*De: *"Stephan Herrmann"
*À: *"John Rose" , jigsaw-dev@openjdk.java.net
"restricted keywords" + helping automatic modules
Date: Fr 19 Mai 2017 07:27:31 CEST
From: John Rose
To: Stephan Herrmann
On May 18, 2017, at 1:59 AM, Stephan Herrmann
wrote:
In all posts I could not find a real reason against escaping,
aside from aesthetics. I don't see this as su
E provides functionality 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
Here 'transitive' is an existing package name for example. Who
guarantees that there are no packages out there with 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 ex
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 usi
(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 ke
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 perspectiv
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, w
grammar this is.
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 He
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 i'v
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 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 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
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 compil
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 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 semanti
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 clearly
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 questio
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
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 g
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
+ sourcefolde
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
Disable all warnings
Rémi
- Mail original -
De: "Stephan Herrmann"
À: 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:
interesting !
It's now a w
original -
De: "Robert Scholte"
À: 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
wrote:
On 01/21/2017 06:52 PM, fo...@univ-mlv.fr wrote:
Robert,
How do
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 don't
On 01/14/2017 02:38 AM, Alex Buckley wrote:
On 1/13/2017 3:52 PM, Stephan Herrmann wrote:
Speaking of which, I'm confused by these sentences:
7.2:
"The host system is free to decide that a compilation unit containing a
module declaration is not, in fact, associated with the modul
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/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. Is that
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
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 unambiguousl
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 a
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 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 lo
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
On 11/16/2016 11:01 PM, Jonathan Gibbons wrote:
On 11/16/2016 01:41 PM, Stephan Herrmann wrote:
At the end of the day we need full pattern matching right?
Not really, at least, not in javac.
Words like 'module', 'requires', etc are lexed as identifiers. When we get to
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 TypeDe
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 o
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 p
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 compile
81 matches
Mail list logo