Re: Why is it allowed to have several modules with the same name?

[Jonathan Gibbons]

If the two modules with the same name are in different positions on the 
module path, the first one will be seen and will completely hide any 
subsequent occurrences of modules with the same name.


If two modules with the same name are found in the same directory on the 
module path, such as in differently-named jar files, then that is an 
error, because neither can be said to have precedence and hide the other.


-- Jon

On 12/26/20 3:29 AM, Gunnar Morling wrote:

Hi,

So far it was my assumption that the module system would reject
multiple modules with the same name to be present.

But this seems not to be the case; if I have two versions of a module JAR
on my module path -- i.e. two modules which have the same module name and
export the same set of packages -- the java command does not complain (nor
does javac or jlink). Is this an expected behavior?

Thanks,

--Gunnar

Re: -Xdoclint unrecognized in JDK16 due to new module

[Jonathan Gibbons]

On 12/15/20 12:26 AM, Alan Bateman wrote:

On 14/12/2020 20:05, Benjamin Marwell wrote:

Hello all,

it caught my attention that doclint functionality was moved to the
jdk.javadoc module [1].

Now, when calling ToolProvider.getSystemJavaCompiler().getTask(…), the
presence of the option '-Xdoclint:-missing' and similar options will 
throw

this exception [2]:
    java.lang.IllegalArgumentException: error: invalid flag:
-Xdoclint:-missing.

This call is being used in Apache Maven, and the Apache Zookeper project
already suffers from this issue and reported it upstream [3].

Adding the modules to the maven script 'mvn' did not help. But when 
calling
javac as an external tool (i.e. not via ToolProvider in the same 
process),

the options are being recognized.

I wonder how the doclint options can be made available to
the ToolProvider.getSystemJavaCompiler().getTask(…) call again.
Maven itself (and in this case: the compiler plugin) is, as you know, a
non-modular project.
I think the Plexus Classworlds launcher sets a funky TCCL that impacts 
the ServiceLoader lookup of DocLint providers. Can the ServiceLoader 
usage in DocLint be changed to use the system class loader rather than 
the TCCL to see if that "fixes it"?


-Alan.



Filed as https://bugs.openjdk.java.net/browse/JDK-8258443

-- Jon

Re: -Xdoclint unrecognized in JDK16 due to new module

[Jonathan Gibbons]

Ben,

jdk.compiler "uses" a service that "jdk.javadoc" provides, so as long as 
"jdk.javadoc"
is available in the image bring executed, I would expect jdk.javadoc to 
be linked in.


There is different minor issue that the system could fail in a more 
friendly way

when the jdk.javadoc module is not available.

-- Jon

On 12/14/20 12:05 PM, Benjamin Marwell wrote:

Hello all,

it caught my attention that doclint functionality was moved to the
jdk.javadoc module [1].

Now, when calling ToolProvider.getSystemJavaCompiler().getTask(…), the
presence of the option '-Xdoclint:-missing' and similar options will throw
this exception [2]:
java.lang.IllegalArgumentException: error: invalid flag:
-Xdoclint:-missing.

This call is being used in Apache Maven, and the Apache Zookeper project
already suffers from this issue and reported it upstream [3].

Adding the modules to the maven script 'mvn' did not help. But when calling
javac as an external tool (i.e. not via ToolProvider in the same process),
the options are being recognized.

I wonder how the doclint options can be made available to
the ToolProvider.getSystemJavaCompiler().getTask(…) call again.
Maven itself (and in this case: the compiler plugin) is, as you know, a
non-modular project.

Best regards,
Ben

[1] https://bugs.openjdk.java.net/browse/JDK-8252712
[2]
https://github.com/bmarwell/maven-compiler-plugin/runs/1546156526?check_suite_focus=true
[3] https://bugs.openjdk.java.net/browse/JDK-8253996

Re: javac --module option and stale classes

[Jonathan Gibbons]

On 7/29/20 5:49 AM, Christian Stein wrote:

I wonder whether the logic at [1] is a) the sole place that
controls this feature and b) whether it can be enhanced
to also prune stale classes from previous javac runs.


That should be the only place.

The minor complication about pruning stale classes is that
it is not a 1-1 mapping from .java to .class files, and that for
a perfect job, you have to read the .class file to determine the
likely origin of the .java file. For a good but not perfect job,
you can apply heuristics to the filename, and whether it contains
'$' characters or not.

-- Jon

Re: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH

[Jonathan Gibbons]

CSR and patch look good to me.

-- Jon


On 05/13/2019 06:02 AM, Jan Lahoda wrote:

Thanks Alex!

Could I please get a review on the CSR?

https://bugs.openjdk.java.net/browse/JDK-8222396

And also on the patch:
http://cr.openjdk.java.net/~jlahoda/8220702/webrev.01/

Thanks!

Jan

On 06. 05. 19 21:06, Alex Buckley wrote:

On 4/12/2019 12:03 PM, Alex Buckley wrote:

On 4/12/2019 5:34 AM, Jan Lahoda wrote:

I've started with the CSR here:
https://bugs.openjdk.java.net/browse/JDK-8222396


Looks pretty good. I made some edits to record both of your
single-module and multi-module invocations of javac.

The use case of injecting test code is clear, but the exact connection
between automatic modules and test code is pretty opaque. Is the 
goal to
make the automatic test module read the explicit test module so that 
the
former module's code can access the latter module's code? Is the 
goal to

make the automatic module read (and therefore test) at least the same
set of modules as the explicit modules `requires`?


Reviewing the CSR again, it seemed like the key scenario is multiple 
named modules, where for each named module:


1. We don't really care about its relationship with the other named 
modules; but


2. We do care about injecting it with test code, and letting that 
test code read other, completely arbitrary, modules (say, an 
assertion-building library that's been placed on the module path).


I have refactored the CSR to more strongly separate the problem 
(patching an automatic module is possible, but readability is 
sub-par) from the solution (precedent for ALL-MODULE-PATH from the 
unnamed module scenario).


JEP 261 should be updated to explain the awesome power of 
--patch-module at compile time, and that is progressing behind the 
scenes, but I don't think it needs to block JDK-8220702 -- the CSR is 
"good enough" documentation for now.


Alex

Re: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH

[Jonathan Gibbons]

On 4/10/19 3:07 PM, Alex Buckley wrote:

On 4/10/2019 2:51 PM, Jonathan Gibbons wrote:

On 4/10/19 11:51 AM, Alex Buckley wrote:

There is a question to be answered: When the compiler compiles code in
an automatic module (due to the code being observed in a directory
that is specified to --patch-module), then what is the _default set of
root modules_ for the automatic module?

I expect the answer is: the same as the default set of root modules
for the unnamed module.


I would not expect the fact that you're compiling code in one or more
automatic modules to have any effect on the module graph. The fact that
the definitions of some types have been "patched in" using source code
via --patch-module is (or should be) irrelevant.


I'm not sure how anyone compiles code as if in an automatic module, 
since the automatic module is solely a JAR file, but Jan suggests that 
it's possible to patch an automatic module's content with the source 
files being compiled. So, I looked in JEP 261 to see how javac would 
treat those source files:


"If a module descriptor in the form of a module-info.java or 
module-info.class file is specified on the command line [NO], or is 
found on the source path [NO] or the class path [NO], then source 
files will be compiled as members of the module named by that 
descriptor and that module will be the sole root module. Otherwise if 
the --module  option is present [NO] then source files will be 
compiled as members of , which will be the root module. 
Otherwise [I GUESS WE'RE HERE] source files will be compiled as 
members of the unnamed module, and the root modules will be computed 
as described above."


Alex


It sounds like JEP 261 should be updated with more info about patching 
modules, since "you are not here" where you guess we are.


At compilation time, --patch-module allows any content to be "patched 
in" to any module in the module graph. The content may be provided in 
source form or compiled form. In either case, the context for any names 
mentioned in the content is determined by the module being patched, and 
its dependencies.


-- Jon

Re: Way to bypass "uniquely visible" check for named vs. unnamed module conflict?

[Jonathan Gibbons]

Bug filed:

https://bugs.openjdk.java.net/browse/JDK-8215739

-- Jon


On 12/20/2018 11:46 AM, Alex Buckley wrote:

Thank you Stephan. We're looking into javac now.

(BTW I enjoyed your comment on SO that "Adding module-info.java is not 
part of the problem, but part of the solution (thereby moving your 
code from classpath to modulepath)".)


Alex

On 12/20/2018 5:21 AM, Stephan Herrmann wrote:

Sorry, if that part was left implicit.
Yes, all versions of javac that I tried accept all four invocations.
This includes the following builds:
- 9.0.4+11
- 10.0.1+10
- 11.0.1+13-LTS
- 12-ea+19

Stephan


On 20.12.18 00:05, Alex Buckley wrote:

I'm seeing multiple claims in the SO item 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:

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 javax.xml.transform.Transformer;

public class Test {
 Transformer transformer;
}
//---

Which of the following compiler invocations should accept / 
reject the

program:

$ javac Test.java
$ javac -classpath xml-apis-1.4.01.jar Test.java
$ javac -classpath xml-apis-1.4.01.jar
--limit-modules=java.base,java.xml Test.java
$ javac -classpath xml-apis-1.4.01.jar --limit-modules=java.base
Test.java

From my understanding, only the first and the last invocations
should succeed. In both other cases the code in Test.java 
(associated

to the unnamed module) can access package javax.xml.transform both
from module java.xml and from the unnamed module containing
xml-apis-1.4.01.jar. (I say "the unnamed module" but I don't seen 
any

impact if an implementation would choose to support several unnamed
modules).


I agree that only the first and last invocations should succeed.

As you described in an Eclipse bug
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=536928), the qualified
type name `javax.xml.transform.Transformer` mentions a package
`javax.xml` that is NOT uniquely visible. In particular, and assuming
a single unnamed module: when compiling an ordinary compilation unit
(Test.java) associated with the unnamed module (the classpath), there
IS an ordinary compilation unit (some file in xml-apis-1.4.01.jar)
associated with the unnamed module which contains a declaration of 
the

package; but the unnamed module also reads the java.xml module that
exports the package to the unnamed module.

tl;dr A package split between the classpath and the system image is
just as bad as a package split between two modules on the modulepath.

Alex

Re: Where do empty compilation units belong?

[Jonathan Gibbons]

On 11/26/2018 01:44 PM, Alex Buckley wrote:
// Adding compiler-dev since the parsing of files into compilation 
units is not a Jigsaw issue.


On 11/20/2018 9:14 PM, Jayaprakash Artanareeswaran wrote:

"jigsaw-dev"  wrote on 21/11/2018
01:56:42 AM:
 > Jon points out that `OrdinaryCompilationUnit` will match an empty 
stream

 > of tokens (I dislike the syntax-driven optionality here, but it's
 > longstanding) so the file D.java could be regarded as a 
compilation unit

 > with no package declaration, no import declarations, and no type
 > declarations.
 >
 > Per JLS 7.4.2, such a compilation unit is in an unnamed package, and
 > must be associated with an unnamed module.
 >
 > I would prefer 7.4.2 to say only that a compilation unit with no 
package

 > declarations _and at least one type declaration_ is in an unnamed
 > package (and must be associated with an unnamed module; 7.3 should
 > enumerate that possibility). A compilation unit with no package
 > declarations _and no type declarations_ would be deemed 
unobservable by

 > 7.3, and all these questions about what to do with empty files would
 > disappear.

That would be perfect and make things unambiguous. But for now, the
paragraph above is good enough for me.


Unfortunately, import declarations can have side effects (compile-time 
errors) so to be sure that the "no package or type decl === 
unobservable" rule is suitable for a file containing just an import 
decl, we would have to do a case analysis of how javac and ecj handle 
the eight combinations of the three parts allowed in an ordinary 
compilation unit. That's overkill for the situation involving empty 
files that keeps coming up and that I really want to clarify. I don't 
think anyone loves that an ordinary compilation unit matches the empty 
stream, so let's define away that scenario. As Jon said, an empty file 
doesn't present anything to be checked; there is no compilation unit 
there, so let's be unambiguous about that.


We can rule out the empty stream in 7.3 with grammar or with 
semantics. Usually a semantic description is clearest (gives everyone 
the proper terminology and concepts) but in this case we don't want 
the description to wrestle with "consists of one, two, or three parts" 
when the grammar allows zero. So, a new grammatical description is 
appropriate, and straightforward:


  OrdinaryCompilationUnit:
    PackageDeclaration {ImportDeclaration} {TypeDeclaration}
    ImportDeclaration {ImportDeclaration} {TypeDeclaration}
    TypeDeclaration {TypeDeclaration}

The "three parts, each of which is optional" description is still 
accurate. The package decl part is optional (as long as you have the 
import decls part and/or the type decls part); the import decls part 
is optional (as long as you have either the package decl part or ...) 
... you get the picture.


I would leave 7.4.2 alone; an ordinary compilation unit with no 
package or type decls but with import decls is part of the unnamed 
package (and thus unnamed module) as before, and compilers can handle 
that, I think.


Any comments?

Alex


That seems good to me.

To summarize the javac behavior ...

 * javac accepts/ignores an empty file
 * javac treats import-only compilation units as in the unnamed
   package, which is not allowed in a named module
 * javac enforces file naming constraints when declaring a public class
 * javac uses file naming constraints when looking on the (module)
   source path for a file for a class


Attached is a toy class to generate combinations of package, import and 
type declarations. You can use the source-launcher feature to run it.


-- Jon

Re: Where do empty compilation units belong?

[Jonathan Gibbons]

On 11/20/2018 12:26 PM, Alex Buckley wrote:

On 11/20/2018 10:54 AM, Alex Buckley wrote:

From the above, it's hard to understand for which file an error is
reported by Eclipse. In any case, as Jon indicated, if the file D.java
is empty, then there is no stream of tokens matching the JLS 7.3
production `CompilationUnit` and thus there is no compilation unit to
discuss.


Jon points out that `OrdinaryCompilationUnit` will match an empty 
stream of tokens (I dislike the syntax-driven optionality here, but 
it's longstanding) so the file D.java could be regarded as a 
compilation unit with no package declaration, no import declarations, 
and no type declarations.


Per JLS 7.4.2, such a compilation unit is in an unnamed package, and 
must be associated with an unnamed module. (The "must" somewhat 
conflicts with the "may" in 
https://docs.oracle.com/javase/specs/jls/se11/html/jls-7.html#jls-7.3-310)


I would prefer 7.4.2 to say only that a compilation unit with no 
package declarations _and at least one type declaration_ is in an 
unnamed package (and must be associated with an unnamed module; 7.3 
should enumerate that possibility). A compilation unit with no package 
declarations _and no type declarations_ would be deemed unobservable 
by 7.3, and all these questions about what to do with empty files 
would disappear.


What do compiler engineers think?

Alex


I think that would be useful but not necessary, since we are dealing 
with the way the host system finds/handles compilation units.


It is the case that javac accepts and effectively ignores empty files; 
that is nothing new or specific to the module system or 
module-source-path. javac doesn't go out of its way to ignore them; it's 
more that there is nothing in an empty file that needs to be checked.  
Yes, 7.4.2 says that an empty file is in an unnamed package in an 
unnamed module,  and yes you can say it is weird to allow them in a 
hierarchy on the module source path, but it would be equally weird to 
forbid empty files in subdirectories of directories on the source path 
or module source path. javac does reject non-empty compilation units 
without a package declaration that are associated with a named module.


Generally, in addition to the various suggestions in JLS 7 regarding 
restrictions that may be enforced when packages are stored in a file 
system, javac uses the following rules in being a "host system" (7.2)


 * Types that are looked up implicitly on the source path or module
   source path must be in an appropriately named directory.

 * Module membership is determined by examining the search path for
   each module on the module source path to determine which search path
   contains a directory that indirectly contains any given file. If
   there is only one source hierarchy for each module, that simplifies
   to finding the module declaration in the enclosing directory on the
   module source path.

-- Jon

Re: Where do empty compilation units belong?

[Jonathan Gibbons]

On 11/19/18 9:27 PM, Jayaprakash Artanareeswaran wrote:

I have the following folder structure in a module

my.module
  -module-info.java
  - p
  -- C.java
  -- q
  --- D.java

where C.java contains only the package declaration and D.java is empty.

When I run javac with --module-source-path and all the individual files as arguments the 
compiler is happy and reports no error. This behavior is different from Eclipse compiler 
which reports an error about "declaring a named package because this compilation 
unit is associated to the named module". Is this because empty compilation units are 
considered to be part of unnamed modules or because the D.java and hence package q are 
omitted?

I have been trying to find out the relevant part of the spec or any 
documentation that defines this behavior, but couldn't find anything on this. 
Can someone please tell me what the right behavior is and point me to the 
relevant documentation?

This Eclipse bug has more details - 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=540067

Regards,
Jay



As long as C.java contains a package declaration for "package p;", I 
would expect that to be OK. There is (or should be) no presumption about 
what other declarations may appear in that file.


If D.java is empty, there is nothing to complain about!

Generally, javac cares about the contents of files, as defined by the 
syntax rules in JLS.   The conventions about filenames only kick in when 
applied to a type element declared in that file.


-- Jon

Improving module source path for javac and javadoc

[Jonathan Gibbons]

There has been some recent discussion over the use of the javac and javadoc
`--module-source-path` options (and the lack of adequate documentation 
thereof).


To help provide content for documentation, I created some examples, 
based on the
use cases in the recent discussions, and came up against some issues 
that led me

to some ideas for improving the way that the module source path for `javac`
and `javadoc` can be set.

As background, I note that the `--module-source-path` option was 
designed very

early on in what is now the design of Jigsaw. It was designed when the
collective mindset was about single instances of non-repeatable options, 
and it
had to support the JDK source structure. It was also designed before the 
rewrite

of the JDK build system that allowed much more flexibility in terms of
computing and setting options. The module source path also has to 
support the
ability to have a "leaky"[^1] path for the directories that provide the 
source
for a single module, while maintaining the strong encapsulation that is 
desired

for the overall set of modules on the module path.

Because of all that, it has a relatively complicated syntax. It was 
intended to

provide flexibility for a variety of use cases, and for the most part it
succeeds, at the cost of some unfamiliar complexity. That being said, it has
always made one fundamental assumption that prevents a category of use 
cases:
the assumption is that there will always be a directory named for the 
module in

the overall path for any directory containing source for the module.
For example, the directory `my.module` in the following file tree for a 
module

named `my.module`:

/my/library/my.module/src/share/classes/module-info.java
my/classes/C.java

The problem arises when working with a set of modules that do not follow 
that
file naming convention, which is now seen to arise for some folk when 
working

on modularizing existing libraries. Curiously, the problem is less likely to
arise with `javac`, because when compiling such a set of modules, you can
compile the modules one at a time "bottom-up", using single-module mode and
`--source-path`, placing all previously compiled modules on the module path
with `--module-path`. But with `javadoc`, you are more likely to want to
present the _source_ for all modules together to the tool, to be able to 
build

a single documentation bundle for the overall set of modules.

You can almost workaround the problem by (ab)using `--patch-module`, which
allows you to specify a path to override the contents of a module, and for
`javac` and  `javadoc`, you can put source in the patch path as well as 
classes.
But `--patch-module` cannot be used to add arbitrary modules: any module 
being

patched must also exist somewhere on the main module path.

That workaround hints at a solution, and a corresponding follow-up 
discussion on

naming.

Proposal


Allow the module source path to be specified in a manner similar to the
`--patch-module`. The argument to `--patch-module` is of the form:

  `=`  (   )*

This would allow a specific path to be specified for the source code  of any
individual module.  In the same way as for `--patch-module`, different 
values

could be specified for different modules.

Whether or not to add a new option or modify the existing option is 
discussed

separately, later.

Whatever the name of the option, it would be a repeatable option that can be
specified once for each module to be compiled, allowing a standard
(package-oriented) source path to be specified for each module.

This is just a proposal about the syntactic form of how the module 
source path

is specified; there is no change to the underlying semantics of the module
source path. In particular, the effect in relation to any other options
specifying the locations of modules (including `patch-module`) is not 
affected.


Given the arcane nature of the value of the existing option, it is 
possible that

we might wish to eliminate the existing mechanism over a suitable period of
time. It has served its purpose, but the new proposal is a better, simpler
replacement.

The internal implementation for such a proposal is already supported at the
API level: see [StandardJavaFileManager.setLocation][setLocation]. This API
was added relatively late in JDK 9, to solve what was essentially the same
problem, as encountered by IDEs wanting to configure a file manager through
the API.  (This proposal can be viewed as surfacing that API to the 
command-line

option.)

Dropping the Old Form
-

While the existing form is concise for compilation environments with lots of
modules, and with many source directories contributing to each module 
(such as
shared source, platform-specific source, and generated source), that 
advantage
is diminished in environments with only a few simple modules, which is 
the more
common case. It may be that most users would prefer to always use the 
new form:

while more verbose, 

Re: The baby and the bathwater (the return)

[Jonathan Gibbons]

Rémi,

Generally, you should consider the runtime "module path" to be composed 
of three elements: the upgrade module path (--upgrade-module-path), the 
system modules (--system) and the user module path (--module-path).  
Depending on your requirements, you may want to take --patch-module into 
account as well.  At compile time there is also the source path 
(--source-path or --module-source-path) to consider.


While this may seem complicated, it is analagous of the pre-Jigsaw world of

    -Xbootclasspath/p:  -bootclasspath  -Xbootclasspath/a: -classpath   
(and -sourcepath at compile time)


-- Jon


On 6/3/18 12:43 PM, Remi Forax wrote:

Hi all,
There were discussions on that list [1] about the fact that beginning with Java 
9, there were 2 ways to deploy modules, classpath vs module-path.

I've discovered last Friday there that are not 2 configurations but 3 
configurations.
You can also use jlink [2] and in that case, the modules are not loaded though 
the module-path but are considered as system modules, so a library should also 
be tested with that configuration.

In my case, Spring Boot annotations scanning works with the classpath, works 
with the module-path but fails if deployed as system modules [3].

regards,
Rémi


[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-March/013689.html
[2] http://openjdk.java.net/jeps/282
[3] https://github.com/forax/pro-demo/tree/master/spring-demo

Re: Deprecated attribute in module-info.class?

[Jonathan Gibbons]

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/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 Deprecated attribute.

Is this intended? JVMS 4.7.15 neither includes nor excludes
modules, but not generating the Deprecated attribute looks
like an omission to me.

Are you using `javap` to look at the class or something else?

I ask because `javap` tool was updated in JDK 10 to render 
annotations in a more friendly way. When I use the JDK 10 `javap` 
to look at the jdk.xml.bind's module-info.class from JDK 9 I see:


RuntimeVisibleAnnotations:
   0: #5(#6=s#7,#8=Z#9)
 java.lang.Deprecated(
   since="9"
   forRemoval=true
 )

whereas the JDK 9 `javap` prints less useful output.


I did use JDK 9 javap, but was able to decipher the
RuntimeVisibleAnnotations attribute as you can see above :)
(Still good to know about the improvement in JDK 10).

My question, however, concerns the lack of a Deprecated
*attribute* a la JVMS 4.7.15.

Is that intended or not?

IOW, are compilers expected to evaluate RuntimeVisibleAnnotations
in order to issue deprecation warnings?
In the past this was not necessary.

best,
Stephan


Stephan,

Given JEP 277 [1], it is now necessary to read the annotation in order
to determine if the annotated item has been deprecated for removal,
and to act accordingly.


That's true, I was just hoping, we could skip evaluating
RuntimeVisibleAnnotations if no Deprecated attribute is found.

Is using Deprecated attributes now deprecated ? :p

Stephan



Stephan,

Check these rules [1] which apply for class files with ACC_MODULE set:

 *

   |attributes|: One|Module|attribute must be present. Except
   
for|Module|,|ModulePackages|,|ModuleMainClass|,|InnerClasses|,|SourceFile|,|SourceDebugExtension|,|RuntimeVisibleAnnotations|,
   and|RuntimeInvisibleAnnotations|, none of the pre-defined attributes
   (§4.7
   <https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.7>)
   may appear.

-- Jon

[1] 
https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.1 
(see the end of this section)

Re: Deprecated attribute in module-info.class?

[Jonathan Gibbons]

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 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 generating the Deprecated attribute looks
like an omission to me.

Are you using `javap` to look at the class or something else?

I ask because `javap` tool was updated in JDK 10 to render 
annotations in a more friendly way. When I use the JDK 10 `javap` to 
look at the jdk.xml.bind's module-info.class from JDK 9 I see:


RuntimeVisibleAnnotations:
   0: #5(#6=s#7,#8=Z#9)
 java.lang.Deprecated(
   since="9"
   forRemoval=true
 )

whereas the JDK 9 `javap` prints less useful output.


I did use JDK 9 javap, but was able to decipher the
RuntimeVisibleAnnotations attribute as you can see above :)
(Still good to know about the improvement in JDK 10).

My question, however, concerns the lack of a Deprecated
*attribute* a la JVMS 4.7.15.

Is that intended or not?

IOW, are compilers expected to evaluate RuntimeVisibleAnnotations
in order to issue deprecation warnings?
In the past this was not necessary.

best,
Stephan


Stephan,

Given JEP 277 [1], it is now necessary to read the annotation in order
to determine if the annotated item has been deprecated for removal,
and to act accordingly.

-- Jon

[1] http://openjdk.java.net/jeps/277

Re: RFR: JDK-8194141: Remove JDK9Wrappers

[Jonathan Gibbons]

Updated webrev, reverting unnecessary change to generated-configure.sh

http://cr.openjdk.java.net/~jjg/8194141/webrev.01/

-- Jon

On 01/03/2018 01:44 PM, Jonathan Gibbons wrote:
Please review this code to remove a "temporary" class from javac, to 
provide reflective access to JDK 9 API, so that javac itself could be 
built with JDK 8.  This temporary class is no longer required, now 
that the boot JDK for JDK 10 onwards is JDK 9.


This is primarily about replacing the use of a javac internal class 
with the underlying direct API calls. However, a minor change to the 
autoconf spec is also required, to grant compile-time access to some 
internal JDK API. Some comments from the jdk.compiler module-info are 
also updated.


The fix is proposed for JDK 11.

JBS: https://bugs.openjdk.java.net/browse/JDK-8194141
Webrev: http://cr.openjdk.java.net/~jjg/8194141/webrev.00

-- Jon

RFR: JDK-8194141: Remove JDK9Wrappers

[Jonathan Gibbons]

Please review this code to remove a "temporary" class from javac, to 
provide reflective access to JDK 9 API, so that javac itself could be 
built with JDK 8.  This temporary class is no longer required, now that 
the boot JDK for JDK 10 onwards is JDK 9.


This is primarily about replacing the use of a javac internal class with 
the underlying direct API calls. However, a minor change to the autoconf 
spec is also required, to grant compile-time access to some internal JDK 
API. Some comments from the jdk.compiler module-info are also updated.


The fix is proposed for JDK 11.

JBS: https://bugs.openjdk.java.net/browse/JDK-8194141
Webrev: http://cr.openjdk.java.net/~jjg/8194141/webrev.00

-- Jon

Re: 8191867: Module attribute in 54.0+ class file cannot contains a requires java.base with ACC_TRANSITIVE or ACC_STATIC_PHASE

[Jonathan Gibbons]

There should probably be an equivalent javac update.

-- Jon


On 12/6/17 7:42 AM, Alan Bateman wrote:
The draft JVMS for Java SE 10 forbids an entry in the requires table 
of a Module attribute in a 54.0 or newer class file to require 
java.base with the ACC_TRANSITIVE or ACC_STATIC_PHASE modifiers. This 
needs an update to the module-info.class parser:

   http://cr.openjdk.java.net/~alanb/8191867/webrev/

For now, the ModuleDescriptor.Builder API is not updated but arguably 
it should so that it retains its alignment with what is allowed and 
not allowed in the Java Language.


-Alan

Re: 8192973: Adding "Resolution" to javadoc search index

[Jonathan Gibbons]

Is "resolution" too broad a term?  Should the indexed term be more 
specific, like "module resolution"?


-- Jon

On 12/04/2017 10:36 AM, mandy chung wrote:

+1

Mandy

On 12/4/17 6:45 AM, Alan Bateman wrote:
I'd like to add a search term to the javadoc search to make it easy 
to find the Resolution spec. Attached is the proposed patch. In terms 
we will need to do the same for service binding.


-Alan

$ hg diff src/java.base/share/classes/java/lang/module/package-info.java
diff -r 0b42613e35bf 
src/java.base/share/classes/java/lang/module/package-info.java
--- a/src/java.base/share/classes/java/lang/module/package-info.java 
Mon Dec 04 13:24:00 2017 +0530
+++ b/src/java.base/share/classes/java/lang/module/package-info.java 
Mon Dec 04 14:32:53 2017 +

@@ -34,7 +34,7 @@
  * will cause a {@code NullPointerException}, unless otherwise 
specified. 

  *
  *
- * Resolution
+ * {@index "Resolution"}
  *
  *  Resolution is the process of computing how modules depend on 
each other.

  * The process occurs at compile time and run time. 

Re: Combining -classpath and module-info?

[Jonathan Gibbons]

On 11/07/2017 02:25 PM, Stephan Herrmann wrote:

Thanks a lot, Jon,

This is very helpful.

As you mention legacy mode as "no modules being compiled", this mode
is still tied to the -source, -target, and --release options, right?


Strongly related, yes, but not directly tied together.

Set aside the use of the "legacy" word for a bit.

When -source, -target and/or --release imply compiling for versions of 
the platform
preceding JDK 9, there is no concept of modules, and so there is no 
concept of
"module mode". Thus, there is only "classpath mode" when compiling for 
these

older versions of the platform (JDK 8 and before).

But you can also have "classpath mode" when compiling for JDK 9 (and 
later).
For the most part, the same  commands that can be used to compile code 
in JDK 8
should also work in JDK 9.(Obviously, there are some differences, 
related to the use
of advanced options like -bootclasspath, or to access internal API.)  
But conceptually,
a javac invocation just using -classpath, -sourcepath and -d, and not 
using any
module declarations (in either module-info.java or module-info.class) 
should work
the same on JDK 9 as on JDK 8. Put another way, an average-Joe developer 
wanting
to compile a  simple jar file can use JDK 9 just like he/she previously 
used JDK 8.


That is the sense in which I use the term "legacy mode" as an alias for
"classpath mode". Although I don't particularly like the term "legacy mode",
it does carry strong connotations of "the same as before".

Now, when the developer starts working with modules, and introducing
their own module declarations, that's when javac switches to "module mode"
and the rules that I described previously will apply.




IOW, the fact that the command line without module-info.java succeeds
is not owed to using a different compilation mode, but to compiling
everything in the same unnamed module, right?


That would be another way of looking at it, and a reasonable way for anyone
already knowledgeable about the terminology of the module system.
Compiling code with --release 8, or compiling code without a module 
declaration
with --release 9 should be effectively equivalent.  It's just that you 
can't talk about

the unnamed module in the context of --release 8 and earlier.




Does JEP 261 have a process for correcting the text after it has been 
delivered?


Which space should I watch for updates?
- http://openjdk.java.net/jeps/261
- https://bugs.openjdk.java.net/browse/JDK-8061972
- any other?


I'll leave it to others to respond on this point, but yes, it does seem 
we need an update.


-- Jon



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 .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 doesn't (cannot resolve any types from junit4.jar):
$ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java 
src/module-info.java
The module you are compiling doesn't read the unnamed module. You 
can't write "requires $CLASSPATH" for example.


If you add `--add-reads =ALL-UNNAMED` to the command line 
then it should compile.


-Alan


Thanks, Alan, that would work.

But that is not what I meant when referring to JEP 261.

In JEP 261 I see (under "Single-module mode"):
"It is possible to put arbitrary classes and JAR files on the class 
path in this mode,
 but that is not recommended since it amounts to treating those 
classes and JAR files as

 part of the module being compiled."

Doesn't this say, my above command line treats junit4.jar as part of 
the current module,

*not* as an unnamed module?

Is everything referenced via -classpath definitely treated as an 
unnamed module?

Independent of single-/multi-module modes?

Stephan


Stephan,

I think you have identified some outdated text that needs to be fixed.

The text was correct at one point, when the distinction between 
"single module mode"

and "multi-module mode" was a bigger deal.

These days, the primary distinction is between "classpath (legacy) 
mode" (no modules being compiled)

and "module mode" (one or more modules being compiled.)

Here's how javac treats these modes:

In classpath (legacy) mode ...

* the sourcepath, classpath and output directory behave as 
previously, such as in JDK 8.


In module mode ...

* all classes on the classpath (-classpath) are treated as part of 
the unnamed module.


* if you are just compiling a single module, you may either put the 
source for that module
on the sourc

Re: Combining -classpath and module-info?

[Jonathan Gibbons]

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 .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 doesn't (cannot resolve any types from junit4.jar):
$ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java 
src/module-info.java
The module you are compiling doesn't read the unnamed module. You 
can't write "requires $CLASSPATH" for example.


If you add `--add-reads =ALL-UNNAMED` to the command line 
then it should compile.


-Alan


Thanks, Alan, that would work.

But that is not what I meant when referring to JEP 261.

In JEP 261 I see (under "Single-module mode"):
"It is possible to put arbitrary classes and JAR files on the class 
path in this mode,
 but that is not recommended since it amounts to treating those 
classes and JAR files as

 part of the module being compiled."

Doesn't this say, my above command line treats junit4.jar as part of 
the current module,

*not* as an unnamed module?

Is everything referenced via -classpath definitely treated as an 
unnamed module?

Independent of single-/multi-module modes?

Stephan


Stephan,

I think you have identified some outdated text that needs to be fixed.

The text was correct at one point, when the distinction between "single 
module mode"

and "multi-module mode" was a bigger deal.

These days, the primary distinction is between "classpath (legacy) mode" 
(no modules being compiled)

and "module mode" (one or more modules being compiled.)

Here's how javac treats these modes:

In classpath (legacy) mode ...

* the sourcepath, classpath and output directory behave as previously, 
such as in JDK 8.


In module mode ...

* all classes on the classpath (-classpath) are treated as part of the 
unnamed module.


* if you are just compiling a single module, you may either put the 
source for that module
on the source path (-sourcepath) or in a directory on the module source 
path (--module-source-path).


* if you are compiling multiple modules, they must be in separate 
directories on the

module source path (--module-source-path).

* javac will implicitly look for previously compiled classes in the 
output directory (-d).
(This is in contrast to the usage in classpath/legacy mode, where it has 
always been common practice

to explicitly put the output directory on the classpath as well.)

-- Jon

Re: setLocationForModule doesn't work as expected

[Jonathan Gibbons]

Oliver,

This looks like:
JDK-8188035: JavaFileManager.listLocationsForModules does not always 
reflect values set through tandardJavaFileManager.setLocationForModule.

https://bugs.openjdk.java.net/browse/JDK-8188035

-- Jon

On 08/09/2017 07:18 AM, Oliver Siegmar wrote:

Hello Jigsaw-experts,

I’m currently struggling with the 
javax.tools.StandardJavaFileManager#setLocationForModule method and wondering 
if someone could point me in the right direction.

I thought, the setLocationForModule method can be used for referencing a 
dependent module to compile another one.

In an example, I have two modules - api and app. The api module compiles fine. 
When I try to compile the app module, I’m using this to set the path of the 
compiled api module:

fileManager.setLocationForModule(StandardLocation.MODULE_PATH, 
NAME_OF_THE_API_MODULE, List.of(PATH_OF_THE_COMPILED_API_MODULE));

Unfortunately the compiler can’t find that dependent module ("error: module not 
found“ when trying to compile module-info.java).

Also, I’ve noticed, that it perfectly works, if I use 
StandardLocation.SYSTEM_MODULES instead of StandardLocation.MODULE_PATH.

I’ve created a quick demo at 
https://github.com/osiegmar/java9-module-path-compile-problem 



Is it my fault or is it a compiler bug?


Bye

Oliver

Re: setLocationForModule doesn't work as expected

[Jonathan Gibbons]

Oliver,

It seems like you're doing something reasonable. We'll have to 
investigate and get back to you.


-- Jon


On 8/9/17 7:18 AM, Oliver Siegmar wrote:

Hello Jigsaw-experts,

I’m currently struggling with the 
javax.tools.StandardJavaFileManager#setLocationForModule method and wondering 
if someone could point me in the right direction.

I thought, the setLocationForModule method can be used for referencing a 
dependent module to compile another one.

In an example, I have two modules - api and app. The api module compiles fine. 
When I try to compile the app module, I’m using this to set the path of the 
compiled api module:

fileManager.setLocationForModule(StandardLocation.MODULE_PATH, 
NAME_OF_THE_API_MODULE, List.of(PATH_OF_THE_COMPILED_API_MODULE));

Unfortunately the compiler can’t find that dependent module ("error: module not 
found“ when trying to compile module-info.java).

Also, I’ve noticed, that it perfectly works, if I use 
StandardLocation.SYSTEM_MODULES instead of StandardLocation.MODULE_PATH.

I’ve created a quick demo at 
https://github.com/osiegmar/java9-module-path-compile-problem 



Is it my fault or is it a compiler bug?


Bye

Oliver

Re: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes

[Jonathan Gibbons]

Looks good to me.

-- Jon


On 7/3/17 10:52 AM, mark.reinh...@oracle.com wrote:

2017/6/30 16:08:09 -0700, jonathan.gibb...@oracle.com:

Mark,

The font-family settings in the  nodes were deliberate, and a
workaround for not having time to create a proper taglet for tool guides.

If you remove the style attribute, you'll see in your sample output that
the "Tool Guides" header is in Serif font, but the immediately following
"Since: "  header is in the standard Sans Serif font.

See, for example, this page:
http://cr.openjdk.java.net/~mr/rev/8182776/api/jdk.compiler-summary.html

You're right, but the problem with placing the style attribute on the
`` elements is that it forces the `` text into the sans-serif
font.  That's fine for the tool-guide links, since they're tool names,
but it's wrong for provider descriptions, which are free text (see the
attached image).

The right fix is to repair the Javadoc stylesheet, but the expedient fix
is to tweak the style attributes just where needed, so I've updated the
patch to do the latter:

   http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch
   http://cr.openjdk.java.net/~mr/rev/8182776/api/ (sample output)

- Mark

Re: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes

[Jonathan Gibbons]

On 07/03/2017 10:52 AM, mark.reinh...@oracle.com wrote:

2017/6/30 16:08:09 -0700, jonathan.gibb...@oracle.com:

Mark,

The font-family settings in the  nodes were deliberate, and a
workaround for not having time to create a proper taglet for tool guides.

If you remove the style attribute, you'll see in your sample output that
the "Tool Guides" header is in Serif font, but the immediately following
"Since: "  header is in the standard Sans Serif font.

See, for example, this page:
http://cr.openjdk.java.net/~mr/rev/8182776/api/jdk.compiler-summary.html

You're right, but the problem with placing the style attribute on the
`` elements is that it forces the `` text into the sans-serif
font.  That's fine for the tool-guide links, since they're tool names,
but it's wrong for provider descriptions, which are free text (see the
attached image).

The right fix is to repair the Javadoc stylesheet, but the expedient fix
is to tweak the style attributes just where needed, so I've updated the
patch to do the latter:

   http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch
   http://cr.openjdk.java.net/~mr/rev/8182776/api/ (sample output)

- Mark


Yes, understood. I hadn't realized that "Tool Guides" had been extended 
to "Providers".


-- Jon

Re: Exporting a package with no Java sources

[Jonathan Gibbons]

On 7/3/17 9:11 AM, Alexander Udalov wrote:

Hi Sander,


Have you tried using `--patch-module` during compilation of the Java sources 
(as described in http://openjdk.java.net/jeps/261)? Not sure if it works with 
class files in the patch directory as well, but it sounds like it could address 
your usecase.

This fixes my problem completely (apart from the minor fact that
--patch-module's "use in production settings is strongly discouraged",
according to the JEP). I've confirmed with the Gradle team that this
approach would be fine to compile a mixed-language module.

Thank you!

I think that exhortation applies more to use at runtime. If you're using
it at compile/build time to create a well-formed module that does not
itself need the use of --patch-module, that seems less of an issue.




On Mon, Jul 3, 2017 at 3:14 PM, Alan Bateman  wrote:

On 03/07/2017 12:57, Alexander Udalov wrote:

:
Thanks, a dummy class certainly workarounds the problem of javac
reporting a compilation error here. However, I hope there's a better
way because it'd be a bit strange to force users to create a dummy
Java class in every exported package in pure X modules (replace X with
any JVM language that is not Java).

Moreover, as pointed by Jonathan in his answer, I failed to recognize
a larger problem initially, that it wouldn't be possible to refer to
non-Java classes from Java sources anyway. So what I'm really looking
for instead, is the way to "augment" the module currently compiled by
javac with a directory containing class files, emitted by another
compiler.

Still, this workaround could prove helpful for example if there are
not many exported packages in a module (which I assume would be true
for many modules out there), and there are no Java sources in that
module.


In the module, does the non-Java source code reference the Java code or is
it the other way around? It would be useful for thread to understand the
order that they need to be compiled. As you use the term "augment" then I'm
guessing that the Java code is compiled first, without reference to the
non-Java code.

Maybe a side point for now but I assume the Kotlin compiler doesn't
understand modules yet and so will compile the source "as if" it's in the
unnamed module. This could mean the resulting module is DOA if it references
types in modules that it won't read when the module is resolved.

-Alan

Re: Exporting a package with no Java sources

[Jonathan Gibbons]

On 7/3/17 6:36 AM, Sander Mak wrote:

On 3 Jul 2017, at 15:23, Alexander Udalov 
> wrote:

  But in circumstances where the destination
directory could be different for class files compiled by Java and
non-Java, I see no way to make the Java compiler read the class files
compiled by the non-Java compiler. If they're passed on the classpath
(as they are currently on Java 8 and earlier), the classes there are
not accessible in Java because the named module cannot read the
unnamed module. If they're passed on the module path, they would be
loaded in another module, which is incorrect because semantically it's
the same module.

Have you tried using `--patch-module` during compilation of the Java sources 
(as described in http://openjdk.java.net/jeps/261)? Not sure if it works with 
class files in the patch directory as well, but it sounds like it could address 
your usecase.


Sander


Yes, --patch-module should be able to help.

-- Jon

Re: Exporting a package with no Java sources

[Jonathan Gibbons]

Right now, javac only looks in one location (i.e. directory + its 
subdirectories) for the compiled classes for a module.


It is too late to change this for JDK 9, and even if we could, I think 
we are already pushing the limits of what can be specified on the 
command line to configure the different paths for all the modules 
involved in the compilation.


Converting the error to a warning (as was suggested in the original post 
in this thread) would not address the case where the Java source code 
needs to refer to types declared in class files generated from non-Java 
sources.


-- Jon


On 7/1/17 3:08 AM, Alan Bateman wrote:

On 01/07/2017 10:09, Peter Levart wrote:

Hi Alexander,

Have you tried to put a package-info.java into the exported package? It
might work.

I don't think so, but a dummy class/interface will do (it doesn't have 
to be public). There is a lengthy discussion on this topic in JIRA 
from 2016 that would be useful to link to (but I can't find it just 
now because JIRA is down for maintenance).


-Alan

Re: Explicitly empty sourcepath regression

[Jonathan Gibbons]

On 06/15/2017 09:07 PM, Pepper Lebeck-Jobe wrote:

*Question*
Why must the source files which make up a module be on the source path for
the module to be compiled?


There are a number of aspects to the answer for this.

First, some background.

It has been a decision of long standing that the module membership of a 
compilation
unit is determined by the "host system", which in the case of 
command-line javac,
means by the position of the file in the file system. The alternative, 
which was rejected
early on, was to have to edit every single compilation unit in code that 
was being
modularized to have a module declaration at the top, preceding the 
package declaration.


While it may seem to follow that for any compilation unit, you could 
just look in some
appropriate enclosing directory to find the module declaration, there 
are some
important use cases where that is not enough. Generally, these use cases 
are when
the source for a module is spread across different directory hierarchies 
with different

directories for the package root. The two most common cases of this are when
some of the source for a module is generated, or when the source is a 
combination
of some platform-independent code and some platform specific code. The 
ability to
merge directory hierarchies like this is managed by using paths, as in 
source paths

or class paths.

Now, to some more specific reasons for the design decision.

First ... consistency. It has always been the case for Jigsaw javac that 
when compiling
code from multiple modules together, all the source files given on the 
command line
had to be present on the module source path .. meaning, on the source 
path for
a module on the module source path. That was always required for the 
reasons described
earlier, to be able to determine the module membership of each source 
file specified on
the comment line.  That was initially different from the case of 
compiling a single module,
which initially was more like compiling "traditional" non-modular code. 
In time, it became
clear that was a bad choice and it was better to have the compilation 
requirements
for all modular code be more consistent, whether compiling one module or 
many.


Second ... to avoid obscure errors. In the initial design, when 
compiling a single module,
javac tried to infer the module being compiled from the presence of a 
module declaration
in a compilation unit specified on the command line, or on the source 
path or a module
declaration on the class path.  That led to the possibility of errors in 
which the module
membership  of a compilation unit specified on the command  line (as 
determined by its
position in the file system) could be different from the inferred module 
being compiled.
For example, consider the case where the source path is empty, and the 
command line
contains the source files for the module declaration for one module, and 
the class
declarations for different module. There is no way, in that case, for 
javac to detect the
misconfiguration and give a meaningful message. The solution was to 
require that when
compiling modular code for a single module, all source files must appear 
on the source
path so that javac can ensure that all sources files are part of the 
same module.



That all being said, I understand the concerns that this sets up the 
possibility of
files being implicitly compiled when that is not desired, by virtue of 
being found
on the source path. I also agree that -implicit:none is not an ideal 
solution to the
issue.  In time, we could consider a new option to better address the 
problem.
In the meantime, the short term options are to either synthesize a 
suitable source
directory with links, or to use the Compiler API to provide a custom 
file manager that

uses an equivalent synthetic source path.

-- Jon

Re: Why is -XD-Xmodule hidden?

[Jonathan Gibbons]

On 6/11/17 12:35 AM, Alan Bateman wrote:

On 11/06/2017 08:13, Nicolai Parlog wrote:

  Hi!

When incrementally compiling some of a module's sources it is necessary
to make the compiler aware that the sources actually belong to that
module. One way to do this was the non-standard option -Xmodule, which
was recently demoted to the hidden -XD-Xmodule.

I'm curious to know why.

Example:

javac --module-path mods -d classes
src/foo.mod/com.example.SomeClass.java

This will compile SomeClass in the unnamed module, making it fail if it
uses types from bar.mod (even if foo.mod requires it).

I know of three ways to fix this:

* adding module declaration to compile command
* multi-module declaration
* option -XD-Xmodule

I found the last option to be conceptually most fitting and also the
least troublesome.

-Xmodule was folded into --patch-module some time ago. Just add 
`--patch-module foo.mod=src/foo.jmod` to the above.


I'll have to defer to Jon or Jan as to why -Xmodule wasn't removed. As 
I recall, it was made hidden to allow for transition but I thought 
that was temporary.




There are some tests which still need to be changed to use 
--patch-module.  Once all uses of -Xmodule have been removed from tests, 
we will remove the (hidden/undocumented) option.


-- Jon


-Alan

Re: Request Review: JDK-8181639 Add tool and services information to module summary

[Jonathan Gibbons]

On 06/07/2017 03:36 AM, Alan Bateman wrote:
I agree a taglet would be useful here, especially as the style 
specified to the "dl" tag is copied to many places. 


Agreed, but it seemed too late to add that. We'll need to do a round of 
cleanup for javadoc support for modules.


-- Jon

Re: 8174823: Module system implementation refresh (3/2017)

[Jonathan Gibbons]

Alan,

langtools changes are OK.

-- Jon

On 03/21/2017 02:42 PM, Alan Bateman wrote:
We have been accumulating changes in the jake forest for the last few 
weeks to align with the proposals in JSR 376 and also to pick up API 
changes and bug fixes. It's time to bring these changes into jdk9/dev. 
The issue to bring these changes into jdk9/dev in bulk has been 
approved via the FC extension process (still in use during JDK 9 RDP2).


A summary of the main changes is listed in JDK-8174823 [1], and the 
webrevs with the changes to bring to jdk9/dev are here:

   http://cr.openjdk.java.net/~alanb/8174823/1/

The changes are currently based on jdk-9+161 and will be rebased 
before pushing.


-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8174823

Re: ALL-UNNAMED module does not export all packages from classpath

[Jonathan Gibbons]

Pavel,

It looks like you have tripped over an issue in javac's handling of an 
automatic module, and its ability to read classes from the unnamed 
module (i.e. classpath).


-- Jon


On 03/20/2017 03:19 PM, Pavel Bucek wrote:

Hi Alex,

The usecase is about compiling tests in maven projects.

I mirrored the content of the zip to github: 
https://github.com/pavelbucek/reproducer (project contains useful README)


The TestCase.java [1] contains simple testcase, compilable when 
everything is on the classpath.


When module-info.java is added to the standard sources of a maven 
module, the compilation changes from "put everything on classpath" to 
"put test dependencies on classpath, standard dependencies on module 
path", which results in:


javac -d target/test-classes -classpath 
lib/junit-4.12.jar:lib/hamcrest-core-1.3.jar:lib/mockito-core-2.7.17.jar:lib/byte-buddy-1.6.11.jar:lib/byte-buddy-agent-1.6.11.jar:lib/objenesis-2.5.jar 
--module-path target/classes -target 9 -source 9 -Xmodule:tst 
--add-reads tst=ALL-UNNAMED src/test/java/tst/TestCase.java


Test classes are effectively "patched" into main module (here called 
"tst") and the module requires "ALL-UNNAMED", to be able to use test 
dependencies.


I'm not sure about exact cause, but seems like the ALL-UNNAMED module 
doesn't automatically export all packages, only those which were 
analyzed as required by some other module.


When TestCase.java doesn't "import 
org.mockito.stubbing.OngoingStubbing", classpath compilation is ok, 
since we are not using that type directly. But it is part of the 
fluent builder pattern, used on line 18 [2]. If there is a mechanism 
which decides which package is required, it omitted the return type of 
called "when" method, which caused the error. When the package is 
explicitly imported, the error is gone and compilation proceeds as 
expected.


Regards,
Pavel


[1] 
https://github.com/pavelbucek/reproducer/blob/master/src/test/java/tst/TestCase.java
[2] 
https://github.com/pavelbucek/reproducer/blob/master/src/test/java/tst/TestCase.java#L18



On 20/03/2017 22:56, Alex Buckley wrote:
I can't figure out which classes are on which path, and why you think 
ALL-UNNAMED should export FROM the classpath when its purpose is to 
export TO the classpath.


Please clarify your configuration in a few short sentences, rather 
than asking us to open a zip file on an unknown host.


Alex

On 3/20/2017 2:44 PM, Pavel Bucek wrote:

// moving from jdk9-dev, as suggested.

Hi Jon,

Thanks for clarification of the error message.

The main point here is that adding "import ... " fixes the issue, which
doesn't feel correct.

When dependencies are put on the classpath, the import statement is not
required.

Regards,
Pavel

On 20/03/2017 22:26, Jonathan Gibbons wrote:

If nothing else, the javac error message needs work.


(package org.mockito.stubbing is declared in module , which does not
export it)


The space between "module" and "," means there's an "empty" module
name there, for the unnamed module, which should have been stated
explicitly (i.e. "declared in the unnamed module").

Follow-ups would be better on jigsaw-dev or compiler-dev.

-- Jon



On 03/20/2017 02:15 PM, Libor Kramolis wrote:

Hello.

I have problem to compile following unit test:
import org.junit.Test;
import static org.junit.Assert.assertEquals;
import static org.mockito.ArgumentMatchers.any;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

public class TestCase {

 @Test
 public void test() {
 Context context = mock(Context.class);
 when(context.test(any())) //returns
org.mockito.stubbing.OngoingStubbing
 .thenReturn("mock");

 assertEquals("mock", context.test("any"));
 }

 interface Context {
 String test(String value);
 }

}
with following error:

src/test/java/tst/TestCase.java:15: error:
OngoingStubbing.thenReturn(T,T...) in package org.mockito.stubbing is
not accessible
 .thenReturn("mock");
 ^
   (package org.mockito.stubbing is declared in module , which does
not export it)
   where T is a type-variable:
 T extends Object declared in interface OngoingStubbing
1 error

Interface org.mockito.stubbing.OngoingStubbing is returned by when(…)
method. And whenever I explicitly import the interface (no other
change in code is necessary) compilation works.

Full reproduced sources are available in zip file at
http://anise.cz/~paja/liba/reproducer.zip
<http://anise.cz/~paja/liba/reproducer.zip>. It contains javac
commands. It is also possible to build it by Maven.

What do you think about this behaviour? It seems to me as a bug. The
import statement is very artificial in this case.

Thanks in advance for your help.

Best regards,
Libor

Re: ALL-UNNAMED module does not export all packages from classpath

[Jonathan Gibbons]

Pavel,

I did not mean to suggest the error message was the only problem. I 
merely wanted to note a subtle detail in the message that might 
otherwise have been easy to overlook, and which might be a clue to the 
underlying problem.


-- Jon

On 03/20/2017 02:44 PM, Pavel Bucek wrote:

// moving from jdk9-dev, as suggested.

Hi Jon,

Thanks for clarification of the error message.

The main point here is that adding "import ... " fixes the issue, 
which doesn't feel correct.


When dependencies are put on the classpath, the import statement is 
not required.


Regards,
Pavel

On 20/03/2017 22:26, Jonathan Gibbons wrote:

If nothing else, the javac error message needs work.

(package org.mockito.stubbing is declared in module , which does not 
export it)


The space between "module" and "," means there's an "empty" module 
name there, for the unnamed module, which should have been stated 
explicitly (i.e. "declared in the unnamed module").


Follow-ups would be better on jigsaw-dev or compiler-dev.

-- Jon



On 03/20/2017 02:15 PM, Libor Kramolis wrote:

Hello.

I have problem to compile following unit test:
import org.junit.Test;
import static org.junit.Assert.assertEquals;
import static org.mockito.ArgumentMatchers.any;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

public class TestCase {

 @Test
 public void test() {
 Context context = mock(Context.class);
 when(context.test(any())) //returns 
org.mockito.stubbing.OngoingStubbing

 .thenReturn("mock");

 assertEquals("mock", context.test("any"));
 }

 interface Context {
 String test(String value);
 }

}
with following error:

src/test/java/tst/TestCase.java:15: error: 
OngoingStubbing.thenReturn(T,T...) in package org.mockito.stubbing 
is not accessible

 .thenReturn("mock");
 ^
   (package org.mockito.stubbing is declared in module , which does 
not export it)

   where T is a type-variable:
 T extends Object declared in interface OngoingStubbing
1 error

Interface org.mockito.stubbing.OngoingStubbing is returned by 
when(…) method. And whenever I explicitly import the interface (no 
other change in code is necessary) compilation works.


Full reproduced sources are available in zip file at 
http://anise.cz/~paja/liba/reproducer.zip 
<http://anise.cz/~paja/liba/reproducer.zip>. It contains javac 
commands. It is also possible to build it by Maven.


What do you think about this behaviour? It seems to me as a bug. The 
import statement is very artificial in this case.


Thanks in advance for your help.

Best regards,
Libor

Re: javac unzips class files from jars on class path into output directory

[Jonathan Gibbons]

-implicit:none is also a good solution, but which solution is best 
depends on your specific situation (i.e. there is no one "best" for 
everyone.)


With -implicit:none, you are allowing javac to determine which kind of 
file to read (source or class) when more than one kind is available for 
any given class, as determined by -Xprefer.  In this case, it would seem 
like javac is choosing to read source files, which may require more 
analysis (i.e. performance cost) than a previously compiled class file.


By setting sourcepath, you are more directly informing javac of where to 
read source files (if any, and if you want that) as compared to class files.


Whether you prefer to have javac read source files or class files 
depends on whether you just want the signatures defined in the class 
file, or whether you want all the info available in the source file, 
and/or whether performance is an issue.


-- Jon

On 03/09/2017 01:13 AM, Doug Simon wrote:

Jon,

Thanks for the insight. I was not aware (or had forgotten) that the classpath 
is also searched for source files. Reading the javac man page, it seems like I 
could also use -implicit:none (I confirmed this works). Is that somehow 
better/cleaner than an empty source path? Of course, since I control creation 
of the synthetic jars, I should really just put the sources into a separate zip 
(a la src.zip in the jdk).

-Doug


On 9 Mar 2017, at 02:17, Jonathan Gibbons <jonathan.gibb...@oracle.com> wrote:

Doug,

The jar files in your example contain source code;  therefore javac is not so 
much copying the contents of the classpath to the output directory as it is 
compiling the source it is finding.

Two experiments for you.

1.

$ unzip -l jdk.internal.vm.ci.jar | sort -k 4 | head -n 20
- ---
   1710248 444 files
Archive:  jdk.internal.vm.ci.jar
-  -- -   
   990  2017-03-07 15:27   jdk/vm/ci/aarch64/AArch64$1.class
  7936  2017-03-07 15:27   jdk/vm/ci/aarch64/AArch64.class
  1607  2017-03-07 15:27   jdk/vm/ci/aarch64/AArch64$CPUFeature.class
  1212  2017-03-07 15:27   jdk/vm/ci/aarch64/AArch64$Flag.class
 10478  2017-03-07 15:27   jdk/vm/ci/aarch64/AArch64.java
  1414  2017-03-07 15:27   jdk/vm/ci/aarch64/AArch64Kind$1.class
  4121  2017-03-07 15:27   jdk/vm/ci/aarch64/AArch64Kind.class
  3833  2017-03-07 15:27   jdk/vm/ci/aarch64/AArch64Kind.java
   980  2017-03-07 15:27   jdk/vm/ci/amd64/AMD64$1.class
  9034  2017-03-07 15:27   jdk/vm/ci/amd64/AMD64.class
  2931  2017-03-07 15:27   jdk/vm/ci/amd64/AMD64$CPUFeature.class
  1161  2017-03-07 15:27   jdk/vm/ci/amd64/AMD64$Flag.class
 11763  2017-03-07 15:27   jdk/vm/ci/amd64/AMD64.java
  2207  2017-03-07 15:27   jdk/vm/ci/amd64/AMD64Kind$1.class
  5333  2017-03-07 15:27   jdk/vm/ci/amd64/AMD64Kind.class
  5384  2017-03-07 15:27   jdk/vm/ci/amd64/AMD64Kind.java

2. In your example, set the sourcepath to be empty. That will force javac to 
look for source files on the sourcepath (where it won't find any), and only 
look for class files on the classpath.

$ rm -rf bin
$ sh run.sh
$ find bin
bin
bin/org
bin/org/graalvm
bin/org/graalvm/compiler
bin/org/graalvm/compiler/api
bin/org/graalvm/compiler/api/runtime
bin/org/graalvm/compiler/api/runtime/GraalRuntime.class
bin/org/graalvm/compiler/api/runtime/GraalJVMCICompiler.class
$

-- Jon


On 03/07/2017 10:11 AM, Doug Simon wrote:

Hi Jon,

I've attached bug.zip which should reproduce the issue (assuming jdk 9 javac is 
on your path):

unzip bug.zip
cd bug
./run.sh
find bin

The last command above should show the extra class files from 
jdk.internal.vm.ci.jar in bin.

-Doug





On 7 Mar 2017, at 18:55, Jonathan Gibbons <jonathan.gibb...@oracle.com>
  wrote:



On 03/07/2017 08:06 AM, Doug Simon wrote:


To be able to develop Graal on JDK 9, we're using the `--release 8` javac 
option and providing jar files for API that is either not in 9 or is not 
exported in 9. Here is a simplified form of a javac command:

javac -cp jdk.internal.vm.ci.jar:jdk.unsupported_sun.misc.Unsafe.jar -d bin/ 
--release 8 
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/*.java

where:

dsimon@kurz-3 ~/h/graal-core> ls 
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/*.java
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/GraalJVMCICompiler.java
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/GraalRuntime.java

I expect 2 class files to be written to bin/. However, I see a number of files 
from jdk.internal.vm.ci.jar in bin:

dsimon@kurz-3 ~/h/graal-core> jar tf jdk.internal.vm.ci.jar | wc -l
  444
dsimon@kurz-3 ~/h/graal-core> find bin/jdk/vm/ci | wc -l
   55

I'm guessing that these are the classes in jdk.internal.vm.ci.jar referenced 
(transitively?) from the Graal sources.

Why is this happening? T

Re: javac unzips class files from jars on class path into output directory

[Jonathan Gibbons]

Doug,

The jar files in your example contain source code;  therefore javac is 
not so much copying the contents of the classpath to the output 
directory as it is compiling the source it is finding.


Two experiments for you.

1.

$ unzip -l jdk.internal.vm.ci.jar | sort -k 4 | head -n 20
- ---
  1710248 444 files
Archive:  jdk.internal.vm.ci.jar
-  -- -   
  990  2017-03-07 15:27 jdk/vm/ci/aarch64/AArch64$1.class
 7936  2017-03-07 15:27 jdk/vm/ci/aarch64/AArch64.class
 1607  2017-03-07 15:27 jdk/vm/ci/aarch64/AArch64$CPUFeature.class
 1212  2017-03-07 15:27 jdk/vm/ci/aarch64/AArch64$Flag.class
10478  2017-03-07 15:27 jdk/vm/ci/aarch64/AArch64.java
 1414  2017-03-07 15:27 jdk/vm/ci/aarch64/AArch64Kind$1.class
 4121  2017-03-07 15:27 jdk/vm/ci/aarch64/AArch64Kind.class
 3833  2017-03-07 15:27 jdk/vm/ci/aarch64/AArch64Kind.java
  980  2017-03-07 15:27   jdk/vm/ci/amd64/AMD64$1.class
 9034  2017-03-07 15:27   jdk/vm/ci/amd64/AMD64.class
 2931  2017-03-07 15:27 jdk/vm/ci/amd64/AMD64$CPUFeature.class
 1161  2017-03-07 15:27 jdk/vm/ci/amd64/AMD64$Flag.class
11763  2017-03-07 15:27 jdk/vm/ci/amd64/AMD64.java
 2207  2017-03-07 15:27 jdk/vm/ci/amd64/AMD64Kind$1.class
 5333  2017-03-07 15:27 jdk/vm/ci/amd64/AMD64Kind.class
 5384  2017-03-07 15:27 jdk/vm/ci/amd64/AMD64Kind.java

2. In your example, set the sourcepath to be empty. That will force 
javac to look for source files on the sourcepath (where it won't find 
any), and only look for class files on the classpath.


$ rm -rf bin
$ sh run.sh
$ find bin
bin
bin/org
bin/org/graalvm
bin/org/graalvm/compiler
bin/org/graalvm/compiler/api
bin/org/graalvm/compiler/api/runtime
bin/org/graalvm/compiler/api/runtime/GraalRuntime.class
bin/org/graalvm/compiler/api/runtime/GraalJVMCICompiler.class
$

-- Jon


On 03/07/2017 10:11 AM, Doug Simon wrote:

Hi Jon,

I've attached bug.zip which should reproduce the issue (assuming jdk 9 javac is 
on your path):

unzip bug.zip
cd bug
./run.sh
find bin

The last command above should show the extra class files from 
jdk.internal.vm.ci.jar in bin.

-Doug




On 7 Mar 2017, at 18:55, Jonathan Gibbons <jonathan.gibb...@oracle.com> wrote:



On 03/07/2017 08:06 AM, Doug Simon wrote:

To be able to develop Graal on JDK 9, we're using the `--release 8` javac 
option and providing jar files for API that is either not in 9 or is not 
exported in 9. Here is a simplified form of a javac command:

javac -cp jdk.internal.vm.ci.jar:jdk.unsupported_sun.misc.Unsafe.jar -d bin/ 
--release 8 
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/*.java

where:

dsimon@kurz-3 ~/h/graal-core> ls 
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/*.java
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/GraalJVMCICompiler.java
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/GraalRuntime.java

I expect 2 class files to be written to bin/. However, I see a number of files 
from jdk.internal.vm.ci.jar in bin:

dsimon@kurz-3 ~/h/graal-core> jar tf jdk.internal.vm.ci.jar | wc -l
  444
dsimon@kurz-3 ~/h/graal-core> find bin/jdk/vm/ci | wc -l
   55

I'm guessing that these are the classes in jdk.internal.vm.ci.jar referenced 
(transitively?) from the Graal sources.

Why is this happening? That is, why is javac extracting classes from a jar on 
the classpath and putting them in the output directory?

-Doug

Doug,

Can you provide a more complete test case?

-- Jon

Re: javac unzips class files from jars on class path into output directory

[Jonathan Gibbons]

On 03/07/2017 08:06 AM, Doug Simon wrote:

To be able to develop Graal on JDK 9, we're using the `--release 8` javac 
option and providing jar files for API that is either not in 9 or is not 
exported in 9. Here is a simplified form of a javac command:

javac -cp jdk.internal.vm.ci.jar:jdk.unsupported_sun.misc.Unsafe.jar -d bin/ 
--release 8 
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/*.java

where:

dsimon@kurz-3 ~/h/graal-core> ls 
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/*.java
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/GraalJVMCICompiler.java
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/GraalRuntime.java

I expect 2 class files to be written to bin/. However, I see a number of files 
from jdk.internal.vm.ci.jar in bin:

dsimon@kurz-3 ~/h/graal-core> jar tf jdk.internal.vm.ci.jar | wc -l
  444
dsimon@kurz-3 ~/h/graal-core> find bin/jdk/vm/ci | wc -l
   55

I'm guessing that these are the classes in jdk.internal.vm.ci.jar referenced 
(transitively?) from the Graal sources.

Why is this happening? That is, why is javac extracting classes from a jar on 
the classpath and putting them in the output directory?

-Doug


Doug,

Can you provide a more complete test case?

-- Jon

Re: Confusing error message for inner non-public service provider

[Jonathan Gibbons]

Peter,

The circumstances of the analysis of service providers are very 
different to the normal JLS rules regarding visibility and accessibility 
of named items.


I know that we have some cleanup to do, for javac to "catch up" with the 
latest updates to JLS, especially with regards to the difference between 
"visibility" and "accessibility".   Is that the issue you concerned 
about, or is there something else about this message you find confusing.


-- Jon

On 02/13/2017 09:08 AM, Peter Levart wrote:

Hi,

Just wanted to note that the confusing javac error message is not 
specific to services and service providers.


Take the following example:

src/moda/module-info.java:

module moda {
exports pkga;
}

src/moda/pkga/Outer.java:

package pkga;
class Outer {
public static class Untouchable {
public static void touch() {
throw new AssertionError("Can't touch this!");
}
}
}

src/modb/module-info.java:

module modb {
requires moda;
}

src/modb/pkgb/Intruder.java:

package pkgb;
public class Intruder {
public static void main(String[] args) {
pkga.Outer.Untouchable.touch();
}
}


$ javac -d out --module-path out --module-source-path src `find src 
-name '*.java'`

src/modb/pkgb/Intruder.java:6: error: package pkga is not visible
pkga.Outer.Untouchable.touch();
^
  (package pkga is declared in module moda, which does not export it 
to module modb)

1 error



Regards, Peter


On 02/09/2017 11:49 PM, Vicente Romero wrote:

Hi Alex,

Just to double check, the right javac behavior in this case should be 
to issue similar errors in both cases like:


some position here: error: ServiceImpl is not public in 
com.example.internal; cannot be accessed from outside package
some other position here: error: Outer.ServiceImpl is not public in 
com.example.internal; cannot be accessed from outside package


without mentioning in any case anything about visibility right?

Thanks,
Vicente


On 02/07/2017 02:21 PM, Alex Buckley wrote:

On 2/7/2017 1:11 AM, Gunnar Morling wrote:

 ---
 package com.example;
 public interface SomeService {
 public void foo();
 }
 ---
 package com.example.internal;
 class Outer {

 public static class ServiceImpl implements 
com.example.SomeService {

 public ServiceImpl() {}
 public void foo() {}
 }
 }
 ---
 package com.example.internal;
 class ServiceImpl implements com.example.SomeService {
 public ServiceImpl() {}
 public void foo() {}
 }
 ---
 module com.example {
 exports com.example;
 provides com.example.SomeService with 
com.example.internal.ServiceImpl;

 provides com.example.SomeService with
com.example.internal.Outer.ServiceImpl;
 }
 ---

Essentially, I'm wondering:

* Why Outer.ServiceImpl triggers the error about package visibility
while ServiceImpl doesn't (I had a look at the EDR JLS, but I couldn't
find an explanation for that, happy about any specific pointers).
* Why Outer.ServiceImpl triggers "does not have a default constructor"
(ServiceImpl does not). Maybe a hint would be nice that is caused by
Outer not having public access.


Thanks for showing the code. Since everything in the same module, 
package visibility is not relevant and javac shouldn't mention it.


I suspect that javac is getting tripped up by the fact that 
Outer.ServiceImpl is declared 'public' (as the JLS and ServiceLoader 
both demand) but it isn't widely accessible, even within the 
com.example module, due to Outer's default (package) access. I 
believe the JLS and ServiceLoader rules are correct, so it's a javac 
bug.


Alex

Re: Confusing error message for inner non-public service provider

[Jonathan Gibbons]

On 2/9/17 3:07 PM, Alex Buckley wrote:
All the JLS wants is for the class to be 'public'. 

Alex:

Does that just apply locally to the declaration of the class itself, or 
does it also indirectly apply to any enclosing classes, in the case of a 
nested class?


-- Jon

Re: -Xlog and the module system

[Jonathan Gibbons]

FWIW, I think javac also deserves some amount of similar work.

-- Jon

On 02/01/2017 01:49 PM, Nicolai Parlog wrote:

  Hi Alan,

`-Xdiag:resolver` is awesome! :) I think these messages are great
candidates for info-level messages with the "modules" tag via unified
logging.

Something else I noticed, neither Xlog nor Xdiag help with problematic
configurations - both only start logging after everything checked out,
so with missing modules (for example), they do not provide additional
information.


We will probably re-visit this output at some point but there are
other issues to clear away first.

I can understand that logging might not be the most pressing feature
this close to the release. :)

  so long ... Nicolai



On 01.02.2017 18:20, Alan Bateman wrote:

On 01/02/2017 14:27, Nicolai Parlog wrote:


   Hi!

When playing with `-Xlog:modules*` (down to trace) I hoped for a
little more output that I could use to analyze a configuration.

-Xlog:modules is VM oriented and mostly traces the primitives used to
construct the module graph in the VM.

-Xdiag:resolver is probably closer to what you are looking for. We will
probably re-visit this output at some point but there are other issues
to clear away first.

-Alan.

Re: Javadoc vs Accessibility

[Jonathan Gibbons]

Sorry, cut and paste error; the second occurrence should have been -private.


-public
  --show-module-contents api --show-packages exported 
--show-types public --show-members public


-protected   (the long-standing default)
  --show-module-contents api --show-packages exported 
--show-types protected --show-members protected


-package
  --show-module-contents all --show-packages all --show-types 
package --show-members package


-private
  --show-module-contents all --show-packages all --show-types 
private --show-members private



-- Jon


On 01/31/2017 01:45 AM, Andrew Dinn wrote:

Hi Jonathan,

On 31/01/17 00:05, Jonathan Gibbons wrote:


 From the command-line help, the relevant new options are the following:
. . .
The good news is that you can use the existing simple options, which are
now
internally defined in terms of those new options

 -public
   --show-module-contents api --show-packages exported
--show-types public --show-members public

 -protected   (the long-standing default)
   --show-module-contents api --show-packages exported
--show-types protected --show-members protected

 -package
   --show-module-contents all --show-packages all --show-types
package --show-members package

 -public
   --show-module-contents all --show-packages all --show-types
private --show-members private

Option -public attracts the glory of double billing yet corresponding
onus of double duty in the above help text -- which cannot be right.

Could you provide corrected details of the intended command line options
for the cases that have been elided?

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

Re: Javadoc vs Accessibility

[Jonathan Gibbons]

I see the command line help text has not been updated for the existing 
simple options. That is a bug.


-- Jon



On 01/30/2017 04:05 PM, Jonathan Gibbons wrote:

Nicolai,

The simple answer is "Yes, there will be an easy way to generate 
documentation based on accessibility",

and "yes, the javadoc tool is module aware".

We've added new options that generalize the existing simple options, 
so that you can have detailed
control if you really need it, but the existing options will, to a 
large extent, "do the right thing" and should

be sufficient for the common cases.

From the command-line help, the relevant new options are the following:

--show-members 
  Specifies which members (fields, methods, etc.) will be
  documented, where value can be one of "public", 
"protected",
  "package" or "private". The default is "protected", 
which will
  show public and protected members, "public" will 
show only
  public members, "package" will show public, 
protected and

  package members and "private" will show all members.
--show-module-contents 
  Specifies the documentation granularity of module
  declarations. Possible values are "api" or "all".
--show-packages 
  Specifies which modules packages will be documented. 
Possible

  values are "exported" or "all" packages.
--show-types 
  Specifies which types (classes, interfaces, etc.) 
will be
  documented, where value can be one of "public", 
"protected",
  "package" or "private". The default is "protected", 
which will
  show public and protected types, "public" will show 
only

  public types, "package" will show public, protected and
  package types and "private" will show all types.


That's a lot of options and a lot of text.

The good news is that you can use the existing simple options, which 
are now

internally defined in terms of those new options

-public
  --show-module-contents api --show-packages exported 
--show-types public --show-members public


-protected   (the long-standing default)
  --show-module-contents api --show-packages exported 
--show-types protected --show-members protected


-package
  --show-module-contents all --show-packages all --show-types 
package --show-members package


-public
  --show-module-contents all --show-packages all --show-types 
private --show-members private



There's other useful new options as well:

--expand-requires 
  Instructs the tool to expand the set of modules to be
  documented. By default, only the modules given 
explicitly on
  the command line will be documented. A value of 
"transitive" will
  additionally include all "requires transitive" 
dependencies of
  those modules. A value of "all" will include all 
dependencies

  of those modules.

--module (,)*
  Document the specified module(s)

And so, in principle, to generate the current Java SE API 
documentation, you should be able to go


javadoc ...path.options...  --expand-requires transitive --module 
java.se



Caveat: we are still refining the details of the appearance of some 
pages, particularly the summary

page for a module.


-- Jon


On 01/30/2017 03:28 PM, Nicolai Parlog wrote:

  Hi!

There is an interesting question up on StackOverflow, "How does the
Javadoc deal with the visibility of modules in Java 9?".

http://stackoverflow.com/q/41929425/2525313

It asks whether there will be an easy way to generate documentation
based on accessibility?

Next to an actual answer, any pointer to docs would be appreciated as 
well.


  so long ... Nicolai

Re: Javadoc vs Accessibility

[Jonathan Gibbons]

Nicolai,

The simple answer is "Yes, there will be an easy way to generate 
documentation based on accessibility",

and "yes, the javadoc tool is module aware".

We've added new options that generalize the existing simple options, so 
that you can have detailed
control if you really need it, but the existing options will, to a large 
extent, "do the right thing" and should

be sufficient for the common cases.

From the command-line help, the relevant new options are the following:

--show-members 
  Specifies which members (fields, methods, etc.) will be
  documented, where value can be one of "public", 
"protected",
  "package" or "private". The default is "protected", 
which will
  show public and protected members, "public" will show 
only

  public members, "package" will show public, protected and
  package members and "private" will show all members.
--show-module-contents 
  Specifies the documentation granularity of module
  declarations. Possible values are "api" or "all".
--show-packages 
  Specifies which modules packages will be documented. 
Possible

  values are "exported" or "all" packages.
--show-types 
  Specifies which types (classes, interfaces, etc.) will be
  documented, where value can be one of "public", 
"protected",
  "package" or "private". The default is "protected", 
which will

  show public and protected types, "public" will show only
  public types, "package" will show public, protected and
  package types and "private" will show all types.


That's a lot of options and a lot of text.

The good news is that you can use the existing simple options, which are now
internally defined in terms of those new options

-public
  --show-module-contents api --show-packages exported 
--show-types public --show-members public


-protected   (the long-standing default)
  --show-module-contents api --show-packages exported 
--show-types protected --show-members protected


-package
  --show-module-contents all --show-packages all --show-types 
package --show-members package


-public
  --show-module-contents all --show-packages all --show-types 
private --show-members private



There's other useful new options as well:

--expand-requires 
  Instructs the tool to expand the set of modules to be
  documented. By default, only the modules given 
explicitly on
  the command line will be documented. A value of 
"transitive" will
  additionally include all "requires transitive" 
dependencies of
  those modules. A value of "all" will include all 
dependencies

  of those modules.

--module (,)*
  Document the specified module(s)

And so, in principle, to generate the current Java SE API documentation, 
you should be able to go


javadoc ...path.options...  --expand-requires transitive --module 
java.se



Caveat: we are still refining the details of the appearance of some 
pages, particularly the summary

page for a module.


-- Jon


On 01/30/2017 03:28 PM, Nicolai Parlog wrote:

  Hi!

There is an interesting question up on StackOverflow, "How does the
Javadoc deal with the visibility of modules in Java 9?".

http://stackoverflow.com/q/41929425/2525313

It asks whether there will be an easy way to generate documentation
based on accessibility?

Next to an actual answer, any pointer to docs would be appreciated as well.

  so long ... Nicolai

Re: What is the purpose of --inherit-runtime-environment

[Jonathan Gibbons]

Previously, in JDK 8 and before, javac would use the runtime 
bootclasspath if there was explicit setting for the compilation 
bootclasspath.


Now, in 9, there is no sense of a bootclasspath, since it has been 
superseded by modules and the module graph. But even so, it is 
reasonable to ask the question, should javac (be able to) start 
initializing its compilation module graph from the runtime module 
graph?  --inherit-runtime-environment was an attempt to explore that 
possibility. In particular, if you use options like --add-reads, 
--add-exports, etc when initializing the JVM used to run javac, should 
jave pick up those options, as well as honoring explicit settings for 
those options on the javac command line.


The alternative is that javac should have its own well-defined rules for 
defining the compilation module graph (fully independent of the module 
graph for the javac runtime).  If you want the compilation module graph 
to have some similarities to the underlying runtime module graph, that 
you would need to explicitly provide a similar set of options to javac.


I think the growing consensus is that the latter case is the better 
practice.


-- Jon


On 01/20/2017 05:29 PM, Nicolai Parlog wrote:

  Hi!

Pretty much what the subject line says... I don't quite get what exactly
--inherit-runtime-environment does and what it is good for. Is this
something that non-JDK developers are likely to use?

  so long ... Nicolai

Re: Reusing module name token `*` in -d

[Jonathan Gibbons]

Gregg,

javac's new behavior for the output directory is only enabled when javac 
is compiling one or more modules in multi-module mode, which is 
signified by using the --module-source-path option. In other words, if 
(and only if) you are compiling many modules together using 
--module-source-path, then javac will automatically use the extra 
directory level to keep separate the classes for the different modules 
being compiled.


If you have a "legacy" javac command line that works on JDK 8, it will 
work the same way on JDK 9, and so you will get the expected 
package-oriented output in the class output directory (i.e. without any 
additional directory.) That applies whether or not you also specify 
-source 1.6.


-- Jon



On 01/27/2017 02:19 PM, Gregg Wonderly wrote:

I think this is an important detail to consider as well.  If -d’s argument will now 
have an implied subdirectory before the class hierarchy, simple Java 
applications/deployment tools will break, unless the JVM knows exactly what to do 
about this.  However, think about the case where I am building with JDK-9.  What 
happens with "—source 1.6”  would that cause this behavior to change?

Gregg


On Jan 27, 2017, at 10:00 AM, Peter Levart <peter.lev...@gmail.com> wrote:

Hi,

On 01/27/2017 03:27 PM, Nicolai Parlog wrote:

Being able to compile a bunch of modules together, and put the
resulting single output directory on the module path would seem to
be more convenient and thus more desirable.

You make it sound like it's "either or" but that would not be the
case. It would be "either you use the asterisk" or "I can reuse the
same path for the module path".

Perhaps the asterisk is not the right solution for distributing generated 
classes into non-standard output paths. It implies that compiled module classes 
will be written to a path that has a component in common with source path (i.e. 
the asterisk) and that this component is equal to module name. Asterisk is 
already used in --module-source-path to construct paths that aggregate sources 
for a particular module residing in different directories, for example:

--module-source-path 
/Users/Me/MyProject/src/*/{linux,shared}:/Users/Me/MyProject/build/gensrc/*

The asterisk has a special meaning here. It is a placeholder that gets replaced 
with the same module name in all places it appears to construct a list of 
directories containing the package subdirectories with sources for a particular 
module.

You now want to extend the meaning of asterisk to -d option, which implies that 
the output directory containing package subdirectories with generated classes 
for a particular module will contain a component that is equal to module name. 
This might not always be what is desired.

We can already specify individual modules (either modular jars or exploded modules) on 
the --module-path, which is important for tools such as Maven. So maybe a complementary 
feature could be to specify a "distribution" list of output paths per module:

--module-output 
module.one=/path/to/module-one/classes,module.two=/path/to/module-two/classes,...

--module-output would be complementary to -d option. When a module it not 
listed in the --module-output, its classes are written to a common tree 
specified by -d.

This is just a thought.

Regards, Peter





On 26.01.2017 19:15, Jonathan Gibbons wrote:

On 1/26/17 6:30 AM, Nicolai Parlog wrote:

Hi,

I see that this feature is unlikely to be in Java 9 ;) , but I
want to give it one last push before conceding:


Comparing the two ways of compiling a set of modules ...

Compiling modules one at a time (when that is possible) is the
smallest overall change for both the IDE and developer. Each
module can be compiled and built separately, and the resulting
modules can be put individually on the module path.

Compiling modules together may yield a faster overall
compilation times, and the use of a single output directory
makes it much easier to set up the module path at runtime.

Compiling all modules at once with a module name token in the
path "may yield faster overall compilation times" and "the
resulting modules can be put individually on the module path".
Looks like a mix of characteristics that is otherwise not
possible to achieve convenientl y.

so long ... Nicolai

That does not seem to be an obviously desirable combination.

Being able to compile a bunch of modules together, and put the
resulting single output directory on the module path would seem to
be more convenient and thus more desirable.

-- Jon


On 25.01.2017 23:50, Jonathan Gibbons wrote:

Stephan,

There will be many cases where one project contains one module
and for those cases, the single module mode compilation will
be sufficient and bears the most similarity to the way people
organize their project today.

At the other end of the scale, there will be cases where a set
of closely-coupled modules have t

Re: Reusing module name token `*` in -d

[Jonathan Gibbons]

Peter,

I concede that a hypothetical new --module-output option might address 
the problem, but I'm still not convinced there is a problem that needs 
to be addressed.


The use case appears to be a desire to compile together a set of of 
loosely related projects, each with their own source directory hierarchy 
and class output directory hierarchy. That use case is not a function of 
the module system, and could be said to exist today, for a collection of 
projects to be compiled with JDK 8. And I am not aware that there has 
been any demand for a feature in javac that would allow a set of 
projects to be compiled together but yet have the compiled output placed 
in a corresponding set of class output directories. I don't see that 
adding module-info.java files to each project changes that.


In contrast, the module source path was added as a way of compiling a 
collection of tightly-coupled modules, in a context where it was 
acceptable for the output to be placed in a single module output directory.


-- Jon


On 1/27/17 8:00 AM, Peter Levart wrote:

Hi,

On 01/27/2017 03:27 PM, Nicolai Parlog wrote:

Being able to compile a bunch of modules together, and put the
resulting single output directory on the module path would seem to
be more convenient and thus more desirable.

You make it sound like it's "either or" but that would not be the
case. It would be "either you use the asterisk" or "I can reuse the
same path for the module path".


Perhaps the asterisk is not the right solution for distributing 
generated classes into non-standard output paths. It implies that 
compiled module classes will be written to a path that has a component 
in common with source path (i.e. the asterisk) and that this component 
is equal to module name. Asterisk is already used in 
--module-source-path to construct paths that aggregate sources for a 
particular module residing in different directories, for example:


--module-source-path 
/Users/Me/MyProject/src/*/{linux,shared}:/Users/Me/MyProject/build/gensrc/*


The asterisk has a special meaning here. It is a placeholder that gets 
replaced with the same module name in all places it appears to 
construct a list of directories containing the package subdirectories 
with sources for a particular module.


You now want to extend the meaning of asterisk to -d option, which 
implies that the output directory containing package subdirectories 
with generated classes for a particular module will contain a 
component that is equal to module name. This might not always be what 
is desired.


We can already specify individual modules (either modular jars or 
exploded modules) on the --module-path, which is important for tools 
such as Maven. So maybe a complementary feature could be to specify a 
"distribution" list of output paths per module:


--module-output 
module.one=/path/to/module-one/classes,module.two=/path/to/module-two/classes,...


--module-output would be complementary to -d option. When a module it 
not listed in the --module-output, its classes are written to a common 
tree specified by -d.


This is just a thought.

Regards, Peter






On 26.01.2017 19:15, Jonathan Gibbons wrote:


On 1/26/17 6:30 AM, Nicolai Parlog wrote:

Hi,

I see that this feature is unlikely to be in Java 9 ;) , but I
want to give it one last push before conceding:


Comparing the two ways of compiling a set of modules ...

Compiling modules one at a time (when that is possible) is the
smallest overall change for both the IDE and developer. Each
module can be compiled and built separately, and the resulting
modules can be put individually on the module path.

Compiling modules together may yield a faster overall
compilation times, and the use of a single output directory
makes it much easier to set up the module path at runtime.

Compiling all modules at once with a module name token in the
path "may yield faster overall compilation times" and "the
resulting modules can be put individually on the module path".
Looks like a mix of characteristics that is otherwise not
possible to achieve convenientl y.

so long ... Nicolai

That does not seem to be an obviously desirable combination.

Being able to compile a bunch of modules together, and put the
resulting single output directory on the module path would seem to
be more convenient and thus more desirable.

-- Jon



On 25.01.2017 23:50, Jonathan Gibbons wrote:

Stephan,

There will be many cases where one project contains one module
and for those cases, the single module mode compilation will
be sufficient and bears the most similarity to the way people
organize their project today.

At the other end of the scale, there will be cases where a set
of closely-coupled modules have to be compiled together, and
multi-module mode was designed to address those cases. In this
situation, having the class files end up in a single directory
hierarchy organized by module should not be surpr

Re: Reusing module name token `*` in -d

[Jonathan Gibbons]

On 1/26/17 6:30 AM, Nicolai Parlog wrote:

  Hi,

I see that this feature is unlikely to be in Java 9 ;) , but I want to
give it one last push before conceding:


Comparing the two ways of compiling a set of modules ...

Compiling modules one at a time (when that is possible) is the
smallest overall change for both the IDE and developer. Each module
can be compiled and built separately, and the resulting modules can
be put individually on the module path.

Compiling modules together may yield a faster overall compilation
times, and the use of a single output directory makes it much
easier to set up the module path at runtime.

Compiling all modules at once with a module name token in the path
"may yield faster overall compilation times" and "the resulting
modules can be put individually on the module path". Looks like a mix
of characteristics that is otherwise not possible to achieve convenientl
y.

  so long ... Nicolai

That does not seem to be an obviously desirable combination.

Being able to compile a bunch of modules together, and put the resulting
single output directory on the module path would seem to be more
convenient and thus more desirable.

-- Jon




On 25.01.2017 23:50, Jonathan Gibbons wrote:

Stephan,

There will be many cases where one project contains one module and
for those cases, the single module mode compilation will be
sufficient and bears the most similarity to the way people
organize their project today.

At the other end of the scale, there will be cases where a set of
closely-coupled modules have to be compiled together, and
multi-module mode was designed to address those cases. In this
situation, having the class files end up in a single directory
hierarchy organized by module should not be surprising.

In between, there may be projects that contain a set of loosely
related modules, such that they can be compiled one module at a
time in a topologically sorted order. For these projects, it
becomes a design choice for the IDE vendor and/or a use choice for
the developer whether to use a series of compilations, one per
module, into distinct class output directories, or whether to
compile them all together, and have the classes written to a single
module-oriented output directory. Either way, the effective
compilation will be the same, and the same checks for strong
encapsulation should be in effect between the modules.

(For your example of a set of separate projects, each with its own
sourcefolder and binfolder, I would expect each project to have
its own independent build "script", which each come down to one of
the three preceding cases.)

Comparing the two ways of compiling a set of modules ...

Compiling modules one at a time (when that is possible) is the
smallest overall change for both the IDE and developer. Each module
can be compiled and built separately, and the resulting modules can
be put individually on the module path.

Compiling modules together may yield a faster overall compilation
times, and the use of a single output directory makes it much
easier to set up the module path at runtime.

-- Jon


On 01/25/2017 12:05 PM, Stephan Herrmann wrote:

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 + sourcefolder + binfolder
Project2 + sourcefolder + binfolder ... Note there is nothing
outside of projects. I don't believe this is going to change any
time soon. Tools know how to find .class files in this
structure.

When projects become modules, at first look it sounds compelling
to perform a multi-module compilation on several projects in one
invocation. (Compelling for reasons of "simplicity" as well as
performance ...). If scattering .class files into unrelated
binfolders is not intended, this seems to suggest to forget about
multi-module compilation, and keep compiling one project/module
at a time, where we can specify individual output folders.

Is that the message?

Maybe, at the end of the pipeline there will be one use case
where multi-module compilation will indeed collect "everything"
into one global bin folder, ready for packaging and shipping, but
that would be the least frequently performed use case, and then
it's much easier to just copy / merge (or link) the individual
binfolders into one.

Any positive reasons to consider multi-module builds after all?

thanks, Stephan

On 01/25/2017 07:38 PM, Jonathan Gibbons wrote:


On 1/25/17 12:20 AM, Nicolai Parlog wrote:

Hi Jonathan,

thanks for considering this.


If nothing else, it would require all the module-specific
output directories to be created ahead of time, so that
javac can determine which ones to use

Why would that be the case? It is not necessary to create them now
so why would using asterisk change that?

OK, 

Re: Reusing module name token `*` in -d

[Jonathan Gibbons]

Stephan,

There will be many cases where one project contains one module
and for those cases, the single module mode compilation will be
sufficient and bears the most similarity to the way people organize
their project today.

At the other end of the scale, there will be cases where a set of
closely-coupled modules have to be compiled together, and
multi-module mode was designed to address those cases. In this
situation, having the class files end up in a single directory hierarchy
organized by module should not be surprising.

In between, there may be projects that contain a set of loosely
related modules, such that they can be compiled one module
at a time in a topologically sorted order. For these projects, it
becomes a design choice for the IDE vendor and/or a use choice
for the developer whether to use a series of compilations, one
per module, into distinct class output directories, or whether to
compile them all together, and have the classes written to a
single module-oriented output directory. Either way, the effective
compilation will be the same, and the same checks for strong
encapsulation should be in effect between the modules.

(For your example of a set of separate projects, each with its own
sourcefolder and binfolder, I would expect each project to have its
own independent build "script", which each come down to one of the
three preceding cases.)

Comparing the two ways of compiling a set of modules ...

Compiling modules one at a time (when that is possible) is the
smallest overall change for both the IDE and developer.
Each module can be compiled and built separately, and the resulting
modules can be put individually on the module path.

Compiling modules together may yield a faster overall compilation
times, and the use of a single output directory makes it much easier
to set up the module path at runtime.

-- Jon


On 01/25/2017 12:05 PM, Stephan Herrmann wrote:

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
+ sourcefolder
+ binfolder
  Project2
+ sourcefolder
+ binfolder
  ...
Note there is nothing outside of projects.
I don't believe this is going to change any time soon.
Tools know how to find .class files in this structure.

When projects become modules, at first look it sounds compelling to
perform a multi-module compilation on several projects in one invocation.
(Compelling for reasons of "simplicity" as well as performance ...).
If scattering .class files into unrelated binfolders is not intended,
this seems to suggest to forget about multi-module compilation,
and keep compiling one project/module at a time, where we can specify
individual output folders.

Is that the message?

Maybe, at the end of the pipeline there will be one use case where
multi-module compilation will indeed collect "everything" into one
global bin folder, ready for packaging and shipping, but that would be
the least frequently performed use case, and then it's much easier
to just copy / merge (or link) the individual binfolders into one.

Any positive reasons to consider multi-module builds after all?

thanks,
Stephan

On 01/25/2017 07:38 PM, Jonathan Gibbons wrote:



On 1/25/17 12:20 AM, Nicolai Parlog wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

  Hi Jonathan,

thanks for considering this.


If nothing else, it would require all the module-specific output
directories to be created ahead of time, so that javac can
determine which ones to use

Why would that be the case? It is not necessary to create them now so
why would using asterisk change that?


OK, I missed that you were not suggesting to adopt all of the 
functionality

of module source path, including the ability to specify a path of output
locations, so that module classes could be written into a directory 
that is

more closely associated with the source code.




It has always been the case that a single compilation for
different packages from different libraries would result in the
classes being placed in a single output directory hierarchy, and
that the classes could then be selectively packaged into different
files like .jar files.

It has also always been the case that the compiler had no notion of
projects/artifacts/modules but just of plain source files. ;) That
changed, too, so why not do the same for class files?


If you're compiling modules together, why could you not do
something similar?

I have no particular use case (except writing some demos) but I would
guess that it would make it more comfortable for existing tools to
move towards multi-module compilation.

I don't see any reason why the current design would make it harder
for tools to move towards multi-module compilation.



I also like this idea for its symmetry. You can define inp

Re: Reusing module name token `*` in -d

[Jonathan Gibbons]

On 1/25/17 12:20 AM, Nicolai Parlog wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

  Hi Jonathan,

thanks for considering this.


If nothing else, it would require all the module-specific output
directories to be created ahead of time, so that javac can
determine which ones to use

Why would that be the case? It is not necessary to create them now so
why would using asterisk change that?


OK, I missed that you were not suggesting to adopt all of the functionality
of module source path, including the ability to specify a path of output
locations, so that module classes could be written into a directory that is
more closely associated with the source code.




It has always been the case that a single compilation for
different packages from different libraries would result in the
classes being placed in a single output directory hierarchy, and
that the classes could then be selectively packaged into different
files like .jar files.

It has also always been the case that the compiler had no notion of
projects/artifacts/modules but just of plain source files. ;) That
changed, too, so why not do the same for class files?


If you're compiling modules together, why could you not do
something similar?

I have no particular use case (except writing some demos) but I would
guess that it would make it more comfortable for existing tools to
move towards multi-module compilation.

I don't see any reason why the current design would make it harder
for tools to move towards multi-module compilation.



I also like this idea for its symmetry. You can define input the
compilers input, sorted by modules, with *, so why not do the same for
its output? Conceptually that should be obvious (which does not mean
that there are not plenty if reasons against it).


There is a much stronger, more compelling relationship in play.
The current -d option is designed so that you can put the output
directory on the class path or module path as appropriate.  That's
always been the case for the classpath -- even though source
may come from a variety of directory hierarchies, the compiled
classes are put into a simple directory hierarchy that can be put
on the classpath. Now, with modules, that continues to be the case:
you can put the -d output directory on the runtime module path,
either as a single "exploded module" or as a directory of "exploded
modules". That is a compelling argument in favor of the current
design of the javac output directory.

In contrast, I don't see any compelling advantage to allowing
-d "./*/target/classes"
since that would make it significantly harder to place such a
directory on the runtime module path.

-- Jon



  so long ... Nicolai



On 23.01.2017 20:51, Jonathan Gibbons wrote:

Nicolai,

I don't think this proposal is a good way to go. If nothing else,
it would require all the module-specific output directories to be
created ahead of time, so that javac can determine which ones to
use, which would require additional setup commands to be executed
after a "make clean" or its equivalent in other build systems.

Also, I note that the output directory is typically never the
final location for the compiled classes; it is typically just a
"staging area". It has always been the case that a single
compilation for different packages from different libraries would
result in the classes being placed in a single output directory
hierarchy, and that the classes could then be selectively packaged
into different files like .jar files.   If you're compiling modules
together, why could you not do something similar?

-- Jon



On 01/21/2017 02:00 AM, Nicolai Parlog wrote:

Hi!

Another feature request from the trenches regarding multi-module
compilation. (It is possible that there was a similar thread a
couple of days/weeks (?) back but I didn't find it.)

It would be nice to have the ability to specify module specific
target folders, so they do not automatically end up in
`/`.

It seems obvious (which could very well make it stupid) to reuse
the asterisk here and allow something like

javac --module-path mods --module-source-path
"./*/src/main/java" -d "./*/target/classes" -module
initial.module

I have not thought through how this might or might not work with
multiple module source paths. It looks like the only tractable
approach would be to not allow more than one -d element.

so long ... Nicolai



- -- 


PGP Key:
 http://keys.gnupg.net/pks/lookup?op=vindex=0xCA3BAD2E9CCCD509

Web:
 http://codefx.org
 a blog about software development
 https://www.sitepoint.com/java
 high-quality Java/JVM content
 http://do-foss.de
 Free and Open Source Software for the City of Dortmund

Twitter:
 https://twitter.com/nipafx
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYiF/pAAoJEMo7rS6czNUJx9wP/338lKXahsdkn2x0I3BDRNFK
t2IPuDTyFtzeEEuJjDkFVSIsGxfIWsZRtvUpZT23gZrOQikR+lqmdawYUmob+7pd
ir+1MmxJjUWoVCxd/6n

Re: Reusing module name token `*` in -d

[Jonathan Gibbons]

Nicolai,

I don't think this proposal is a good way to go. If nothing else, it would
require all the module-specific output directories to be created ahead
of time, so that javac can determine which ones to use, which would
require additional setup commands to be executed after a "make clean"
or its equivalent in other build systems.

Also, I note that the output directory is typically never the final location
for the compiled classes; it is typically just a "staging area". It has 
always
been the case that a single compilation for different packages from 
different
libraries would result in the classes being placed in a single output 
directory

hierarchy, and that the classes could then be selectively packaged into
different files like .jar files.   If you're compiling modules together,
why could you not do something similar?

-- Jon



On 01/21/2017 02:00 AM, Nicolai Parlog wrote:

  Hi!

Another feature request from the trenches regarding multi-module
compilation. (It is possible that there was a similar thread a couple of
days/weeks (?) back but I didn't find it.)

It would be nice to have the ability to specify module specific target
folders, so they do not automatically end up in
`/`.

It seems obvious (which could very well make it stupid) to reuse the
asterisk here and allow something like

javac
--module-path mods
--module-source-path "./*/src/main/java"
-d "./*/target/classes"
-module initial.module

I have not thought through how this might or might not work with
multiple module source paths. It looks like the only tractable approach
would be to not allow more than one -d element.

  so long ... Nicolai

Re: Reusing module name token `*` in -d

[Jonathan Gibbons]

Currently (JDK 8), the JDK tool guides come in two flavors, and should 
only differ in the content of the examples, and not in any 
specification-related text.  Yes, you found a Windows version for 
javac.html, but there is also a Unix version, here:


http://docs.oracle.com/javase/8/docs/technotes/tools/unix/javac.html

Having two separate documents is "annoying", and that is something else 
we are looking at.


-- Jon

On 1/22/17 10:15 AM, Stephan Herrmann wrote:

Thanks, Jon,

FWIW, I did search on 
http://docs.oracle.com/javase/8/docs/technotes/tools/windows/javac.html
This brought no result for the simple reason, that no connection is 
made from Xlint to @SW.


Additionally, it feels a bit odd that such documentation should be 
platform-dependent

(see the "windows" path segment in the above URL).

Do you perhaps have a draft of what javac.html will look like for Java 9?

best,
Stephan


On 01/22/2017 07:00 PM, Jonathan Gibbons wrote:

Stephan, Rémi, et al,

Yes, we need to better document the @SuppressWarnings and lint 
options accepted 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 engines can find.
The javac help message doesn't even speak of @SuppressWarnings,
so are we sure this is the same list?

More specifically: the warning of unresolved "to", is that covered
by "module" or "exports", or both?

Stephan

On 01/22/2017 03:50 PM, Remi Forax wrote:

$javac -X
 -Xlint:(,)*
Warnings to enable or disable, separated by comma.
Precede a key by - to disable the specified warning.
Supported keys are:
  all  Enable all warnings
  auxiliaryclass   Warn about an auxiliary class that 
is hidden in a source file, and is used from other files.

  cast Warn about use of unnecessary casts.
  classfileWarn about issues related to 
classfile contents.

  deprecation  Warn about use of deprecated items.
  dep-ann  Warn about items marked as 
deprecated in JavaDoc but not using the @Deprecated annotation.
  divzero  Warn about division by constant 
integer 0.

  emptyWarn about empty statement after if.
  exports  Warn about issues regarding module 
exports.
  fallthrough  Warn about falling through from one 
case of a switch statement to the next.
  finally  Warn about finally clauses that do 
not terminate normally.
  module   Warn about module system related 
issues.
  options  Warn about issues relating to use of 
command line options.
  overloadsWarn about issues regarding method 
overloads.
  overridesWarn about issues regarding method 
overrides.
  path Warn about invalid path elements on 
the command line.
  processing   Warn about issues regarding 
annotation processing.

  rawtypes Warn about use of raw types.
  removal  Warn about use of API that has been 
marked for removal.
  serial   Warn about Serializable classes that 
do not provide a serial version ID.
 Also warn about access to non-public 
members from a serializable element.
  static   Warn about accessing a static member 
using an instance.
  try  Warn about issues relating to use of 
try blocks (i.e. try-with-resources).

  uncheckedWarn about unchecked operations.
  varargs  Warn about potentially unsafe vararg 
methods

  none 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:

interesting !

It's now a warning that you can exclude with 
@SuppressWarnings("module"):
  src/main/java/foo/module-info.java:2: warning: [module] module 
not found: baz

  exports foo to baz;
 ^


JLS 9.6.4.5 @SuppressWarnings:
"Compiler vendors should document the warning names they support 
in conjunction
 with this annotation type. Vendors are encouraged to cooperate to 
ensure that

 the same names work across multiple compilers."

looking forward to seeing this happen,
Stephan


Rémi

- Mail original -

De: "Robert Scholte" <rfscho...@apache.org>
À: jigsaw-dev@openjdk.java.net
Envoyé: Samedi 21 Janvier 2017 20:12:37
Objet: Re: Reus

Re: Reusing module name token `*` in -d

[Jonathan Gibbons]

Stephan, Rémi, et al,

Yes, we need to better document the @SuppressWarnings and lint options 
accepted 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 engines can find.
The javac help message doesn't even speak of @SuppressWarnings,
so are we sure this is the same list?

More specifically: the warning of unresolved "to", is that covered
by "module" or "exports", or both?

Stephan

On 01/22/2017 03:50 PM, Remi Forax wrote:

$javac -X
 -Xlint:(,)*
Warnings to enable or disable, separated by comma.
Precede a key by - to disable the specified warning.
Supported keys are:
  all  Enable all warnings
  auxiliaryclass   Warn about an auxiliary class that is 
hidden in a source file, and is used from other files.

  cast Warn about use of unnecessary casts.
  classfileWarn about issues related to classfile 
contents.

  deprecation  Warn about use of deprecated items.
  dep-ann  Warn about items marked as deprecated 
in JavaDoc but not using the @Deprecated annotation.
  divzero  Warn about division by constant 
integer 0.

  emptyWarn about empty statement after if.
  exports  Warn about issues regarding module 
exports.
  fallthrough  Warn about falling through from one 
case of a switch statement to the next.
  finally  Warn about finally clauses that do not 
terminate normally.

  module   Warn about module system related issues.
  options  Warn about issues relating to use of 
command line options.
  overloadsWarn about issues regarding method 
overloads.
  overridesWarn about issues regarding method 
overrides.
  path Warn about invalid path elements on 
the command line.
  processing   Warn about issues regarding annotation 
processing.

  rawtypes Warn about use of raw types.
  removal  Warn about use of API that has been 
marked for removal.
  serial   Warn about Serializable classes that 
do not provide a serial version ID.
 Also warn about access to non-public 
members from a serializable element.
  static   Warn about accessing a static member 
using an instance.
  try  Warn about issues relating to use of 
try blocks (i.e. try-with-resources).

  uncheckedWarn about unchecked operations.
  varargs  Warn about potentially unsafe vararg 
methods

  none 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 warning that you can exclude with 
@SuppressWarnings("module"):
  src/main/java/foo/module-info.java:2: warning: [module] module 
not found: baz

  exports foo to baz;
 ^


JLS 9.6.4.5 @SuppressWarnings:
"Compiler vendors should document the warning names they support in 
conjunction
 with this annotation type. Vendors are encouraged to cooperate to 
ensure that

 the same names work across multiple compilers."

looking forward to seeing this happen,
Stephan


Rémi

- Mail 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 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 think so:

"It is permitted for the to clause of an exports or opens 
statement to

specify a module which is not observable."
[lang-vm.html 1.1.2 - 2017/1/9]

I assume this will eventually (when??) become part of JLS, right?

cheers,
Stephan



Confirmed. I've added an integration-test to the 
maven-compiler-plugin,

works as expected. No need for cross reference dependencies.

thanks,
Robert

Re: javadoc of modules

[Jonathan Gibbons]

Hi Rémi,


On 1/21/17 1:22 AM, Remi Forax wrote:

For the JDK, there are several kind of modules from a doc perspective,
we have root modules that are available by default, like java.base,
we have implementation modules, those that starts with jdk like jdk.jshell,
and we have modules that are not root modules, i.e. available if you use 
--add-modules, like java.xml.bind.

I think that the javadoc panel that display the avaialble modules, should
- separate the different kind of modules, java.xml.bind should not be mixed 
with java.base if it will not be present in Java 10


I think that information would be better conveyed on an updated overview 
page -- the initial page displayed in the main panel.



- have a way to see implementation modules and their corresponding javadoc.


That would be a different run of javadoc, with different options. Just 
as javadoc generates docs on the classes it is given, with a level of 
detail depending on the options it is given, so too is it with modules.




regards,
Rémi

-- Jon

Re: -classpath vs --class-path

[Jonathan Gibbons]

Nicolai,

We've identified the cause of the issue you reported.  Although javac 
accepts --class-path as an alias for -cp and -classpath, what is notable 
about your example is that it is using "classpath wildcards" (i.e. the 
"*" in -cp "mods/*"), which is implemented within the native javac 
launcher, and not in the mainstream javac code.   And yes, in the code 
in question, --class-path is not supported, and probably should be.


Filed: https://bugs.openjdk.java.net/browse/JDK-8172309

-- Jon

On 01/05/2017 08:33 AM, Jonathan Gibbons wrote:
Thank you for the report. It is obviously intended that these options 
should simply be aliases for each other, but I will see if there is 
something else going on to explain what you are seeing.


-- Jon


On 1/5/17 3:23 AM, Nicolai Parlog wrote:

  Hi,

during experimentation I encountered compiler behavior that I found
rather strange: It looks like the -classpath and --class-path options do
not behave the same way.

In my experiment I create a bunch of modules in 'mods' and then create
the last one by putting the modules on the class path (no reason, just
playing around):

 javac -cp "mods/*" -d classes/advent src/advent/advent/Main.java

This works and '-classpath' does, too, but '--class-path' doesn't. In
that case the compiler complains that the packages contained by the
modules in 'mods' do not exist.

For an executable version see here:

https://github.com/CodeFX-org/demo-jigsaw-advent-calendar/blob/compiling-with-deps-as-modules/compileAndRun.sh#L41-L48 



I noticed this on b146 but it also exists in b148; both EA-Jigsaw 
builds.


  so long ... Nicolai

Re: RFR: 8171400: Move checking of duplicate packages in the boot layer to link time

[Jonathan Gibbons]

Looks OK to me.

-- Jon

On 12/19/2016 02:41 PM, Mandy Chung wrote:

tools/launcher/modules/patch/systemmodules/PatchSystemModules.java needs to be 
updated since ModuleBootstrap now depends on this new method:

diff --git 
a/test/tools/launcher/modules/patch/systemmodules/src1/java.base/jdk/internal/modules/SystemModules.java
 
b/test/tools/launcher/modules/patch/systemmodules/src1/java.base/jdk/internal/modules/SystemModules.java
--- 
a/test/tools/launcher/modules/patch/systemmodules/src1/java.base/jdk/internal/modules/SystemModules.java
+++ 
b/test/tools/launcher/modules/patch/systemmodules/src1/java.base/jdk/internal/modules/SystemModules.java
@@ -29,4 +29,8 @@
   */
  public final class SystemModules {
  public static final String[] MODULE_NAMES = new String[0];
+
+public static boolean hasSplitPackages() {
+return true;
  }
+}

Since this fix has been pushed, I will fix this with a separate issue.

Mandy


On Dec 19, 2016, at 4:30 AM, Claes Redestad  wrote:

Hi,

this patch adds a check to see if there are any split packages in the system
modules at link time, and uses this information to enable us to safely skip
a runtime check during bootstrap for the common case that there are none
of the sort.

Webrev[1]: http://cr.openjdk.java.net/~redestad/8171400/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8171400

This removes a chunk of the module system bootstrap overhead, and also
amends a small issue where PACKAGES_IN_BOOT_LAYER would be wrong in the
presence of split packages.

Thanks!

/Claes

[1] Since cr.openjdk.java.net is down I've also attached the raw patch.

Re: per-module module-source-path for javac

[Jonathan Gibbons]

Thank you for noting the additional use case of CLASS_OUTPUT.

-- Jon


On 12/16/16 8:57 AM, Nikolay Chashnikov wrote:

Hi Jonathan,

thank you, glad to hear it.

Regarding API design: we already have 
JavaFileManager#getLocationForModule which takes Location and 
moduleName, so it looks logical to add setLocationForModule which 
takes location, moduleName and list of paths, as you suggested. It 
would be useful not only for MODULE_SOURCE_PATH, but also for example 
for CLASS_OUTPUT to allow users specify output directories on 
per-module basis. In this way, 'setLocation' method can be used to 
specify paths for all modules at once if they follow the same naming 
scheme, and 'setLocationForModule' can be used if locations of modules 
don't follow any common scheme.


On Fri, Dec 16, 2016 at 5:50 PM, Jonathan Gibbons 
<jonathan.gibb...@oracle.com <mailto:jonathan.gibb...@oracle.com>> wrote:


Nikolay,

We are looking at this.

One aspect of the problem we have to take into account is that
currently, the JavaFileManager API does not special case the
module source path (yes, I know the *implementation* special cases
it, even at the handleOption level) and so we need to come up with
a way providing and specifying the functionality you are looking
for in a way that fits in with the overall design.

-- Jon



On 12/16/16 5:05 AM, Nikolay Chashnikov wrote:

Any comments?

On Mon, Dec 12, 2016 at 8:29 PM, Nikolay Chashnikov <
nikolay.chashni...@jetbrains.com
<mailto:nikolay.chashni...@jetbrains.com>> wrote:

Hello,

we're actively working on support for Jigsaw in IntelliJ
IDEA. Some time
ago we asked (see this post

<http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009713.html

<http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009713.html>>)
about restrictions in --module-source-path parameter of
javac command line.
It appears that currently javac has rather strict
requirements regarding
layout of the source files of multi-module projects on the
disk: module
sources must be located under a directory which name is
equal to the
(qualified) module name, and locations of source
directories for different
modules must follow some common scheme. It's ok for new
projects, but it
complicates migration of existing projects to Jigsaw: you
not only need to
create module-info.java files, get rid of split packages,
etc, but also
most probably you'll need to rearrange directories
containing the sources.
For me, the latter looks like an unnecessary complication,
it may make
migration to Jigsaw more difficult, especially for big
projects developed
by large teams. I think it would be great to allow users
to specify
module-source-path for each module individually.

Given that the implementation
(com.sun.tools.javac.file.Locations.
ModuleSourcePathLocationHandler) already stores paths for
different
modules separately, it seems to be rather easy to expose
ability to specify
module-source-path on per-module basis to
StandardJavaFileManager's API.
    The change in API suggested by Jonathan Gibbons (see this post

<http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009781.html

<http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009781.html>>)
looks good, it will allow us to support arbitrary layout
of sources in
IntelliJ IDEA. Do you plan to implement it? How can we
help you with that?

--
Nikolay Chashnikov
Team Lead
JetBrains
http://www.jetbrains.com
The Drive to Develop







--
Nikolay Chashnikov
JetBrains
http://www.jetbrains.com
The Drive to Develop

hg: jigsaw/jake/langtools: Add support for reading module resolution flags

[jonathan . gibbons]

Changeset: 63af48cfc1c9
Author:jjg
Date:  2016-12-14 17:05 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/63af48cfc1c9

Add support for reading module resolution flags

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java

hg: jigsaw/jake/langtools: enable -Xlint:module by default

[jonathan . gibbons]

Changeset: 4a200166396d
Author:jjg
Date:  2016-12-13 19:23 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4a200166396d

enable -Xlint:module by default

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java

hg: jigsaw/jake/langtools: update module names in tests

[jonathan . gibbons]

Changeset: 7863fba025ea
Author:jjg
Date:  2016-12-13 19:05 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7863fba025ea

update module names in tests

! test/jdk/javadoc/doclet/testModules/TestModules.java
- test/jdk/javadoc/doclet/testModules/module1/module-info.java
- 
test/jdk/javadoc/doclet/testModules/module1/testpkgmdl1/TestClassInModule1.java
- test/jdk/javadoc/doclet/testModules/module2/module-info.java
- 
test/jdk/javadoc/doclet/testModules/module2/testpkg2mdl2/TestInterfaceInModule2.java
- test/jdk/javadoc/doclet/testModules/module2/testpkgmdl2/AnnotationType.java
- 
test/jdk/javadoc/doclet/testModules/module2/testpkgmdl2/AnnotationTypeUndocumented.java
- 
test/jdk/javadoc/doclet/testModules/module2/testpkgmdl2/TestClassInModule2.java
+ test/jdk/javadoc/doclet/testModules/moduleA/module-info.java
+ 
test/jdk/javadoc/doclet/testModules/moduleA/testpkgmdlA/TestClassInModuleA.java
+ test/jdk/javadoc/doclet/testModules/moduleB/module-info.java
+ 
test/jdk/javadoc/doclet/testModules/moduleB/testpkg2mdlB/TestInterfaceInModuleB.java
+ test/jdk/javadoc/doclet/testModules/moduleB/testpkgmdlB/AnnotationType.java
+ 
test/jdk/javadoc/doclet/testModules/moduleB/testpkgmdlB/AnnotationTypeUndocumented.java
+ 
test/jdk/javadoc/doclet/testModules/moduleB/testpkgmdlB/TestClassInModuleB.java
! test/jdk/javadoc/doclet/testModules/moduletags/module-info.java
! test/tools/javac/classfiles/attributes/Module/ModuleTest.java
- 
test/tools/javac/diags/examples/CyclicRequires/modulesourcepath/m1/module-info.java
+ 
test/tools/javac/diags/examples/CyclicRequires/modulesourcepath/m1x/module-info.java
- 
test/tools/javac/diags/examples/CyclicRequires/modulesourcepath/m2/module-info.java
+ 
test/tools/javac/diags/examples/CyclicRequires/modulesourcepath/m2x/module-info.java
- 
test/tools/javac/diags/examples/DuplicateModule/modulesourcepath/m1/module-info.java
+ 
test/tools/javac/diags/examples/DuplicateModule/modulesourcepath/m1x/module-info.java
- 
test/tools/javac/diags/examples/DuplicateModule/modulesourcepath/m2/module-info.java
+ 
test/tools/javac/diags/examples/DuplicateModule/modulesourcepath/m2x/module-info.java
- 
test/tools/javac/diags/examples/HasBeenDeprecatedModule/modulesourcepath/m1/module-info.java
+ 
test/tools/javac/diags/examples/HasBeenDeprecatedModule/modulesourcepath/m1x/module-info.java
- 
test/tools/javac/diags/examples/HasBeenDeprecatedModule/modulesourcepath/m2/module-info.java
+ 
test/tools/javac/diags/examples/HasBeenDeprecatedModule/modulesourcepath/m2x/module-info.java
- 
test/tools/javac/diags/examples/HasBeenDeprecatedRemovalModule/modulesourcepath/m1/module-info.java
+ 
test/tools/javac/diags/examples/HasBeenDeprecatedRemovalModule/modulesourcepath/m1x/module-info.java
- 
test/tools/javac/diags/examples/HasBeenDeprecatedRemovalModule/modulesourcepath/m2/module-info.java
+ 
test/tools/javac/diags/examples/HasBeenDeprecatedRemovalModule/modulesourcepath/m2x/module-info.java
- 
test/tools/javac/diags/examples/LeaksNotAccessible/modulesourcepath/m1/api/Api.java
- 
test/tools/javac/diags/examples/LeaksNotAccessible/modulesourcepath/m1/module-info.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessible/modulesourcepath/m1x/api/Api.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessible/modulesourcepath/m1x/module-info.java
- 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredTransitive/modulesourcepath/m1/api1/Api1.java
- 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredTransitive/modulesourcepath/m1/module-info.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredTransitive/modulesourcepath/m1x/api1/Api1.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredTransitive/modulesourcepath/m1x/module-info.java
- 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredTransitive/modulesourcepath/m2/api2/Api2.java
- 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredTransitive/modulesourcepath/m2/module-info.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredTransitive/modulesourcepath/m2x/api2/Api2.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredTransitive/modulesourcepath/m2x/module-info.java
- 
test/tools/javac/diags/examples/LeaksNotAccessibleUnexported/modulesourcepath/m1/api/Api.java
- 
test/tools/javac/diags/examples/LeaksNotAccessibleUnexported/modulesourcepath/m1/impl/Impl.java
- 
test/tools/javac/diags/examples/LeaksNotAccessibleUnexported/modulesourcepath/m1/module-info.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleUnexported/modulesourcepath/m1x/api/Api.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleUnexported/modulesourcepath/m1x/impl/Impl.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleUnexported/modulesourcepath/m1x/module-info.java
- 
test/tools/javac/diags/examples/LeaksNotAccessibleUnexportedQualified/modulesourcepath/m1/api/Api.java
- 

hg: jigsaw/jake/langtools: disallow -profile with -target 9

[jonathan . gibbons]

Changeset: eb2ed1365493
Author:jjg
Date:  2016-12-13 15:14 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/eb2ed1365493

disallow -profile with -target 9

! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java
! test/tools/javac/diags/examples/NotInProfile.java
! test/tools/javac/profiles/ProfileOptionTest.java

hg: jigsaw/jake/langtools: add filter for opens directives

[jonathan . gibbons]

Changeset: 376da2abfeba
Author:jjg
Date:  2016-12-13 12:59 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/376da2abfeba

add filter for opens directives

! src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java

hg: jigsaw/jake/langtools: fix StackOverflowException handling JCOpens nodes

[jonathan . gibbons]

Changeset: 222acf0cd461
Author:jjg
Date:  2016-12-12 16:41 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/222acf0cd461

fix StackOverflowException handling JCOpens nodes

! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java

Re: javap is not able to read the module-info.class if in a jar

[Jonathan Gibbons]

On 12/04/2016 12:36 AM, Alan Bateman wrote:

On 04/12/2016 00:07, Remi Forax wrote:


Hi all, hi Jon,
while updating ASM6 to the new classfile format, i think i've found a 
bug in javap.


javap as no trouble to read module-info.class if the class is 
specified directly

$ /usr/jdk/jdk-9-jigsaw/bin/javap module-info.class
open module com.google.guava {
   requires java.base;
   requires java.logging;
   requires java.annotations.common;
   requires jdk.unsupported;
   exports com.google.common.io;
   ...
}

but if the module-info.class is in a (modular) jar,
/usr/jdk/jdk-9-jigsaw/bin/javap --module-path deps -m 
com.google.guava module-info
Error: error while reading constant pool for module-info: invalid 
index #0



I've created JDK-8170708 to track this.

-Alan.


There are three issues here:

1. Accessing module-info.class in a .jar file

It may be extreme, javap will accept URLs, including jar: URLs, as 
a way of referencing any .class

file in a .jar file.

2. Better handling of "this_class 0"

3. How to identify the module declaration on the javap command line. 
i.e. should javap be changed

to special case the name module-info?

-- Jon

hg: jigsaw/jake/langtools: rename test class from Aux to Extra to avoid problems on Windows

[jonathan . gibbons]

Changeset: c64079dbb1ba
Author:jjg
Date:  2016-11-30 14:46 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c64079dbb1ba

rename test class from Aux to Extra to avoid problems on Windows

! src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleHelper.java
! test/tools/javac/modules/AnnotationsOnModules.java

hg: jigsaw/jake/langtools: disentangle exports and opens in javac

[jonathan . gibbons]

Changeset: 55e9018d9f89
Author:jjg
Date:  2016-11-29 17:21 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/55e9018d9f89

disentangle exports and opens in javac

! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java
! src/jdk.compiler/share/classes/com/sun/source/tree/ExportsTree.java
+ src/jdk.compiler/share/classes/com/sun/source/tree/OpensTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java
! src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java
! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java
+ test/tools/javac/diags/examples/ConflictingOpens/exported/Class.java
+ test/tools/javac/diags/examples/ConflictingOpens/module-info.java
+ test/tools/javac/diags/examples/ConflictingOpensToModule/module-info.java
+ test/tools/javac/diags/examples/ConflictingOpensToModule/opened/Class.java
! test/tools/javac/modules/ModuleInfoTest.java
! test/tools/javac/tree/TreeKindTest.java

Re: Code review for jigsaw/jake -> jdk9/dev sync up

[Jonathan Gibbons]

On 11/28/16 3:28 AM, Maurizio Cimadamore wrote:

Hi,
the langtools code looks generally ok. Few questions:

* Why doesn't 'open' get its own directive in Directive.java - instead 
of relying on a 'mode' set on an export directive?
I agree that "opens" leveraging a type named "Exports..." is 
particularly irksome. If we don't come up with a common supertype, I 
think we should clone the code.


* ClassReader: should we have checks regarding an open module 
containing no open directives in the classfile? This seems to be 
called out in the spec [1] - see section 2.2


* At some point we should investigate better sharing strategy between 
ClassReader and ModuleNameReader
Maybe, but ModuleNameReader is supposed to be a simple light weight 
class reader, just good enough to get the name. It is invoked from the 
file manager world, and so does not (should not) access anything to do 
with Symbols. If we eventually rewrite ClassReader to sit on top of a 
new lower-level abstraction, then maybe we can share code some more.




* Names.dynamic seems unused

* I note that the classfile attribute name changes are not captured in 
the spec (but I might be referring to a slightly older version).


Maurizio

[1] - http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html#jigsaw-2.2






On 24/11/16 15:25, Alan Bateman wrote:
Folks on jigsaw-dev will know that we are on a mission to bring the 
changes accumulated in the jake forest to jdk9/dev. We can think of 
this as a refresh of the module system in JDK 9, the last big refresh 
was in May with many small updates since then.


The focus this time is to bring the changes that are tied to JSR 
issues into jdk9/dev, specifically the issues that are tracked on the 
JSR issues list [1] as:


#CompileTimeDependences
#AddExportsInManifest
#ClassFileModuleName
#ClassFileAccPublic
#ServiceLoaderEnhancements
#ResourceEncapsulation/#ClassFilesAsResources
#ReflectiveAccessToNonExportedTypes
#AwkwardStrongEncapsulation
#ReadabilityAddedByLayerCreator
#IndirectQualifiedReflectiveAccess (partial)
#VersionsInModuleNames
#NonHierarchicalLayers
#ModuleAnnotations/#ModuleDeprecation
#ReflectiveAccessByInstrumentationAgents

Some of these issues are not "Resolved" yet, meaning there is still 
ongoing discussion on the EG mailing list. That is okay, there is 
nothing final here. If there are changes to these proposals then the 
implementation changes will follow. Also, as I said in a mail to 
jigsaw-dev yesterday [2], is that we will keep the jake forest open 
for ongoing prototyping and iteration, also ongoing implementation 
improvements where iteration or bake time is important.


For the code review then the focus is therefore on sanity checking 
the changes that we would like to bring into jdk9/dev. We will not 
use this review thread to debate alternative designs or other big 
implementation changes that are more appropriate to bake in jake.


To get going, I've put the webrevs with a snapshot of the changes in 
jake here:

http://cr.openjdk.java.net/~alanb/8169069/0/

The changes are currently sync'ed against jdk-9+146 and will be 
rebased (and re-tested) against jdk9/dev prior to integration. There 
are a number of small changes that need to be added to this in the 
coming days, I will refresh the webrev every few days to take account 
of these updates.



A few important points to mention, even if you aren't reviewing the 
changes:


1. This refresh requires a new version of jtreg to run the tests. The 
changes for this new version are in the code-tools/jtreg repository 
and the plan is to tag a new build (jtreg4.2-b04) next week. Once the 
tag has been added then we'll update the requiredVersion property in 
each TEST.ROOT to force everyone to update.


2. For developers trying out modules with the main line JDK 9 builds 
then be aware that `requires public` changes to `requires transitive` 
and the `provides` clause changes to require all providers for a 
specific service type to be in the same clause. Also be aware that 
the binary form of the module declaration (module-info.class) changes 
so you will need to recompile any modules.


3. Those running existing code on JDK 9 and ignoring modules will 
need to be aware of a disruptive change in this refresh. The 
disruptive change is #AwkwardStrongEncapsulation where 
setAccessible(true) is changed so that it can't be used to break into 
non-public fields/methods of JDK classes. This change is going to 
expose a lot of hacks in existing code. We plan to send mail to 
jdk9-dev in advance of this integration to create awareness of this 
change. As per the original introduction of strong encapsulation then 
command line options (and now the manifest of application JAR files) 
can be used to keep existing code working. The new option is 
`--add-opens` to open a package in a module for deep reflection by 
other modules. As an example, if you find yourself with code that 
hacks into the private `comparator` field in 

Re: Replacement for JDK8 APIs

[Jonathan Gibbons]

Stéphan,

You say you are using com.sun.tools.javac.api.JavacTrees. Although that 
class is not exported from jdk.compiler, it is an implementation of the 
interface com.sun.source.util.Trees, which is exported.  Is the 
interface sufficient to your needs? If not, what methods are you calling?


-- Jon


On 11/27/16 1:16 AM, Stéphane Nicoll wrote:

Hey,

Thanks for all the feedback so far. Any idea about the annotation processor
question? Is there a dedicated dev list for it maybe?

Thank you,
S.


On Thu, Nov 24, 2016 at 3:22 PM, Stéphane Nicoll  wrote:


Hi,

I am working on the Spring Boot project[1] and I am trying to make sure
our codebase compiles with the current JDK9 build[2]. So far I've hit two
major issues:

We use "sun.misc.VMSupport" to retrieve the port being used by the Java
remote debugging. You can find the actual code in RemoteDebugPortProvider[3]

We have an annotation processor that inspects all classes annotated with
@ConfigurationProperties and generates some meta-data about them. One
important piece of this is to extract the default value assigned to fields.
Consider the following example

@ConfigurationProperties
public class Foo {

   private static final String DEFAULT_NAME = "name";

   private String name = DEFAULT_NAME;

   private Integer counter = 42;

   private List hosts = Collections.singletonList("localhost");


}

What we've build is a visitor that navigates to those elements and
extracts the default values assigned to each field, including navigating to
parent element (the "name" constant there) or inferring value from method
parameters ("localhost"). The  current code relies on a feature of the JDK
that is no longer exported[4]:


java.lang.IllegalAccessException: class org.springframework.boot.
configurationprocessor.fieldvalues.javac.Trees cannot access class
com.sun.tools.javac.api.JavacTrees (in module jdk.compiler) because
module jdk.compiler does not export com.sun.tools.javac.api to unnamed
module @5a7fe64


Does anybody has some insight as how we could migrate those two use cases?
In particular, the second use case could be implemented with a contract of
javax.lang.model but we haven't found how to do it.

Thank you,
S.



[1] https://github.com/spring-projects/spring-boot
[2] https://github.com/spring-projects/spring-boot/issues/7226
[3] https://github.com/spring-projects/spring-boot/blob/
master/spring-boot-devtools/src/main/java/org/
springframework/boot/devtools/tunnel/server/RemoteDebugPortProvider.java
[4] https://github.com/spring-projects/spring-boot/blob/
master/spring-boot-tools/spring-boot-configuration-
processor/src/main/java/org/springframework/boot/configurationprocessor/
fieldvalues/javac/Trees.java

hg: jigsaw/jake/langtools: 8159607: Update javadoc to support annotations on module-info.java

[jonathan . gibbons]

Changeset: 7678462efbc3
Author:bpatel
Date:  2016-11-23 15:29 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7678462efbc3

8159607: Update javadoc to support annotations on module-info.java
Reviewed-by: jjg

! test/jdk/javadoc/doclet/testModules/TestModules.java
! test/jdk/javadoc/doclet/testModules/module2/module-info.java
+ test/jdk/javadoc/doclet/testModules/module2/testpkgmdl2/AnnotationType.java
+ 
test/jdk/javadoc/doclet/testModules/module2/testpkgmdl2/AnnotationTypeUndocumented.java

hg: jigsaw/jake/langtools: 8168766: javadoc should support deprecation on modules.

[jonathan . gibbons]

Changeset: 98a2842ec26a
Author:bpatel
Date:  2016-11-23 14:01 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/98a2842ec26a

8168766: javadoc should support deprecation on modules.
Reviewed-by: jjg

! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DeprecatedAPIListBuilder.java
! test/jdk/javadoc/doclet/testModules/TestModules.java
! test/jdk/javadoc/doclet/testModules/module1/module-info.java
! test/jdk/javadoc/doclet/testModules/module2/module-info.java
! test/jdk/javadoc/doclet/testModules/moduletags/module-info.java

hg: jigsaw/jake/langtools: Add classfile Module_attribute.OPensEntry

[jonathan . gibbons]

Changeset: 51f0bf95d616
Author:jjg
Date:  2016-11-22 18:42 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/51f0bf95d616

Add classfile Module_attribute.OPensEntry

! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java
! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Module_attribute.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java

hg: jigsaw/jake/langtools: remove support for old-style Module attribute

[jonathan . gibbons]

Changeset: ea87091ceefc
Author:jjg
Date:  2016-11-22 18:18 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ea87091ceefc

remove support for old-style Module attribute

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java
! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Module_attribute.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java

hg: jigsaw/jake/langtools: fix 2 failing tests after Module attribute changes

[jonathan . gibbons]

Changeset: ecda27ca1011
Author:jjg
Date:  2016-11-22 17:49 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ecda27ca1011

fix 2 failing tests after Module attribute changes

! test/tools/javac/classfiles/attributes/Module/ModuleTestBase.java
! test/tools/javac/modules/OpenModulesTest.java

Re: javac --add-modules java.xml.bind for annotation processor?

[Jonathan Gibbons]

On 11/20/16 3:39 PM, Eirik Bjørsnøs wrote:

Turns out that:

a) Maven treats -J arguments in a special way which hides them from the
debug log, but they're still passed on to javac
b) Maven parses the javac output for error messages, but drops any output
not following the javac output format.

So using -J--add-modules=java.xml.bind does actually work!

But my question remains:

What's the difference between -J--add-modules and --add-modules  in javac?

I guess --add-modules specifies modules that javac should allow compilation
against, while -J--add-modules adds modules which should be visible to
javac itself?

That's a pretty good analysis.   javac works with two environments: there's
the "compilation environment" which contains the elements being compiled,
and there's the "runtime environment" which contains the classes for javac
itself, and any annotation processors that are loaded and running.



Eirik.

On Sun, Nov 20, 2016 at 11:45 PM, Eirik Bjørsnøs  wrote:


Claes,

Btw, the annotation processor has been _compiling_ fine all along.

The problem happens when the example-module is compiled with the
annotation-processor on the javac -classpath

Eirik.

On Sun, Nov 20, 2016 at 11:23 PM, Claes Redestad <
claes.redes...@oracle.com> wrote:


Hi Eirik,

compiling com.example.processor.ProcessorUsingJavaXmlBind standalone
seems to work fine with --add-modules java.xml.bind - instead it
appears as if maven-compiler-plugin doesn't preserve argument order, so
you need to use the joined argument form in your pom.xml:

--add-modules=java.xml.bind

I tried this on your minified example, and seems to work. Thanks!

/Claes


On 2016-11-20 22:57, Eirik Bjørsnøs wrote:


Hi there!

I'm giving Java 9 and Jigsaw a spin on a moderately complex project.
(Interestingly, the project is itself a module system, so we do stuff
like
annotation processing and dynamic reloading of class loader graphs and
services)

I'm experienced enough with advanced Java to have shot myself in the foot
with a java.lang.ClassNotFoundException: java.lang.ClassNotFoundExcepti
on
:-) However, I've only recently been looking into Jigsaw in concrete
terms.
So please be kind when I expose my ignorance :-)

Initially, I just want to see if I can get the project to compile on
Java 9.

So I'm using --add-modules to javac here and there to add modules not
available to the unnamed module by default. (Not making any proper
modules
yet, that will be the next step).

This seems to be working fine, except for one of our annotation
processors,
which happens to use JAXBContext from java.xml.bind.

I added --add-modules to javac (via Maven configuration), but my
annotation
processor still can't load JAXBContext and fails with this message:

$ java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+144)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode)

$ mvn clean install -e

This fails with:

Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext
at
com.example.processor.ProcessorUsingJavaXmlBind.process(Proc
essorUsingJavaXmlBind.java:24)
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE
nvironment.callProcessor(JavacProcessingEnvironment.java:959)
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE
nvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:875)
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE
nvironment.access$2100(JavacProcessingEnvironment.java:106)
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE
nvironment$Round.run(JavacProcessingEnvironment.java:1182)
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE
nvironment.doProcessing(JavacProcessingEnvironment.java:1290)
at
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAn
notations(JavaCompiler.java:1260)
at
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(J
avaCompiler.java:939)
at
jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call(Ja
vacTaskImpl.java:106)
at
jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$1.call(Ja
vacTaskImpl.java:100)
at
jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExc
eptions(JavacTaskImpl.java:137)
... 28 more

I've confirmed that this reproduces using only javac:

$ cd example-module

$ javac -d  target/classes -classpath
target/classes:$HOME/.m2/repository/com/example/annotation-p
rocessor/1.0-SNAPSHOT/annotation-processor-1.0-SNAPSHOT.jar:
-sourcepath src/main/java/ -target 1.9 -source 1.9 --add-modules
java.xml.bind src/main/java/com/example/module/SomeClass.java

java.xml? true
java.xml.bind? false


An annotation processor threw an uncaught exception.
Consult the following stack trace for details.
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext
at
com.example.processor.ProcessorUsingJavaXmlBind.process(Proc
essorUsingJavaXmlBind.java:24)
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE
nvironment.callProcessor(JavacProcessingEnvironment.java:959)


I've 

Re: Compiling Java 9

[Jonathan Gibbons]

On 11/16/2016 03:28 PM, Stephan Herrmann wrote:

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, right?

Fictitious counter example

ModuleDeclaration:
  module open Identifier ModuleBody;
  module Identifier ModuleBody;

With this the second token could be keyword or identifier, and we're
stuck, aren't we?

May we assume that the grammar will not be extended in such ambiguous
ways?


There is already a production like this:

ModuleStatement:
  requires transitive ModuleName ;
  requires ModuleName ;


Outch!!

So when you read "requires transitive" which rule are you parsing 
against?

When do you decide whether transitive is a keyword or an identifier?
I guess we have to wait until we matched the full rule.
That requires backtracking, or what am I missing?


Yes, you need to lookahead to a ;

Alex


So everything points at ';' to the rescue.

Unfortunately, while a user types a line of text, this essential
character will be missing until the very end, so tool support
for incomplete lines will not be great.

Not much we can do, I guess.

OK, thanks to you both, I believe I understand the intention.

I guess I made my point that I see tremendous difficulties
in providing good tool support, and that I'm not convinced
that the current definition matches to the intended solution.

I mentioned that all this could probably be avoided by using
an escape mechanism.

That said I will stop harping on these points,
Stephan





It is not quite as bad as that.

An identifier-that-might-be-a-keyword is definitely a restricted keyword 
if it is followed by another identifier (including an 
identifier-that-might-be-a-keyword) or static.


An identifier-that-might-be-a-keyword is definitely an identifier if it 
is followed by a '.' or ';'.


So in the following horrible cases:

requires transitive transitive;
  ^ at this point you know the first 
transitive was a restricted keyword and the second was an identifier


requires transitive transitive.transitive.transitive;
  ^ at this point you know the first 
transitive was a restricted keyword, and that the second and any 
subsequent instances are identifiers.


requires transitive static a.b.c.d.e.f.g.h.i.j;
^ at this point you know transitive was a 
restricted keyword


In other words, you don't need unbounded lookahead.

-- Jon

Re: Compiling Java 9

[Jonathan Gibbons]

On 11/16/2016 02:55 PM, Stephan Herrmann wrote:

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 analyse the
character string "module" in isolation, then yes, you cannot say 
whether it is a keyword or an identifier, but if you know you're in

a ModuleBody, then "exports to to exports;" can be processed just fine.



For syntax highlighting: processing just one line of text would be great.
And the line break could be in the middle of an exports clause.

For error recovery: let's say, s.o. just forgot a ';', we'd like to
search for the next keyword to get back on track parsing.
So even if we started from the top of the file, we don't have the
context for sure, because we don't know where the syntax error happened.
I guess in that case reverting to always seeing restricted keywords as
keywords will give the best heuristics ... but it looks messy to me.


I agree error recovery can be tricky, but if you are before the first 
'{' then the

only restricted keywords are 'open', 'module'.  Once you're inside a module
declaration, ';' is a good recovery point.  ';' is always followed by a 
restricted

keyword, or '}'.



Different tools / tool features have different requirements, a full IDE
will have tens if not hundreds of different use cases in this regard.
Mind you: during editing text with syntax errors is the norm, not the
exception.

Stephan

Re: Compiling Java 9

[Jonathan Gibbons]

On 11/16/2016 02:34 PM, Stephan Herrmann wrote:

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 
is ambiguous until you've looked ahead to lex either 'open',
'module', or a keyword that can start TypeDeclaration. [Ignoring 
annotations for simplicity.]
- If you lexed 'open' or module', then the sequence must parse as 
the second alternative; if you lexed anything else, then the

sequence must parse as the first alternative.


I just tried this:

---8<---
import open.module;

module foo {
}
---8<---

According to lang-vm this should be legal. The import statement
contains restricted keywords in positions where they cannot be 
keywords.

=> Parsing should succeed.
javac rejects this, which supports your explanation that lexical 
lookahead

should suffice to recognize a ModuleDeclaration.

Which one will it be?

Stephan



I suspect you're not using the latest javac.


9-ea-142 gives a syntax error:

module-info.java:3: error: class, interface, or enum expected

I'm downloading 9-ea-144 as we speak.



9-ea-144 probably won't be good enough. You will need a build of the 
jigsaw/jake forest,

coming soon.



Your example works for me, after I also create a class called 
open.module that I can

import.


Thanks, so restricted keywords now follow the same rules throughout 
the file.

Sounds good.

And with your explanation (previous post) I'm confident that javac's 
implementation

and what I had in mind are congruent.

Still curious how a spec will faithfully capture this :)


:-)



Stephan

Re: Compiling Java 9

[Jonathan Gibbons]

On 11/16/2016 02:26 PM, Stephan Herrmann wrote:

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 the point where the grammar would accept one of these
words as a keyword,  we simply check to see if we have an identifier 
with the appropriate value.


-- Jon


OK, feedback from the parser to the scanner to tell it
whether the current context accepts a specific restricted keyword.

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 ModuleBody;
 module Identifier ModuleBody;

With this the second token could be keyword or identifier, and we're 
stuck, aren't we?


May we assume that the grammar will not be extended in such ambiguous 
ways?


I'll leave it to Alex to declare definitively on that, but I think that 
would be a reasonable assumption. :-)




For all tools that read from the start of the file this is good news.

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 analyse the character string 
"module" in isolation, then yes, you cannot say whether it is a keyword 
or an identifier, but if you know you're in a ModuleBody, then "exports 
to to exports;" can be processed just fine.




thanks,
Stephan

Re: Compiling Java 9

[Jonathan Gibbons]

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 
is ambiguous until you've looked ahead to lex either 'open',
'module', or a keyword that can start TypeDeclaration. [Ignoring 
annotations for simplicity.]
- If you lexed 'open' or module', then the sequence must parse as the 
second alternative; if you lexed anything else, then the

sequence must parse as the first alternative.


I just tried this:

---8<---
import open.module;

module foo {
}
---8<---

According to lang-vm this should be legal. The import statement
contains restricted keywords in positions where they cannot be keywords.
=> Parsing should succeed.
javac rejects this, which supports your explanation that lexical 
lookahead

should suffice to recognize a ModuleDeclaration.

Which one will it be?

Stephan



I suspect you're not using the latest javac.   Your example works for 
me, after I also create a class called open.module that I can import.


$ more $(find play/stephan/ -name \*.java)
::
play/stephan/open/module.java
::
package open;

public class module { }

::
play/stephan/module-info.java
::

import open.module;

module foo {
}
$ /opt/jdk/jake/bin/javac -sourcepath play/stephan 
play/stephan/module-info.java

$

-- Jon

Re: Compiling Java 9

[Jonathan Gibbons]

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 the point where the grammar would accept one of these words as a 
keyword,  we simply check to see if we have an identifier with the 
appropriate value.


-- Jon

hg: jigsaw/jake/langtools: 17 new changesets

[jonathan . gibbons]

Changeset: d3dde3f775b8
Author:jlahoda
Date:  2016-11-02 16:48 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d3dde3f775b8

8166538: Improve error reporting for compiling against unexported package
Summary: When a type cannot be found, look into other modules, search for 
possible viable types, and report them conveniently to the user.
Reviewed-by: mcimadamore, jjg

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/PackageClassAmbiguity/util.out
! test/tools/javac/T5003235/T5003235a.java
! test/tools/javac/T5003235/T5003235a.out
! test/tools/javac/T5003235/T5003235b.java
! test/tools/javac/T5003235/T5003235b.out
! test/tools/javac/diags/Example.java
! test/tools/javac/diags/RunExamples.java
! test/tools/javac/diags/examples.not-yet.txt
+ 
test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/NotDefAccessClassIntfCantAccessReason.java
+ 
test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/api1/api1/Api.java
+ 
test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/api1/module-info.java
+ 
test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/api2/api2/Api.java
+ 
test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/api2/module-info.java
+ 
test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/impl/impl/Impl.java
+ 
test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReason/modulesourcepath/impl/module-info.java
+ 
test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/NotDefAccessClassIntfCantAccessReason.java
+ 
test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/api1/api1/Api.java
+ 
test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/api1/module-info.java
+ 
test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/api2/api2/Api.java
+ 
test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/api2/module-info.java
+ 
test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/impl/impl/Impl.java
+ 
test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessReasonFragment/modulesourcepath/impl/module-info.java
- 
test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/NotDefAccessClassPackageCantAccess.java
- 
test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/modulesourcepath/m1/module-info.java
- 
test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/modulesourcepath/m1/p1/C1.java
- 
test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/modulesourcepath/m2/module-info.java
- 
test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/modulesourcepath/m2/p2/C2.java
+ 
test/tools/javac/diags/examples/NotDefAccessDoesNotRead/NotDefAccessDoesNotRead.java
+ 
test/tools/javac/diags/examples/NotDefAccessDoesNotRead/modulesourcepath/api/api/Api.java
+ 
test/tools/javac/diags/examples/NotDefAccessDoesNotRead/modulesourcepath/api/module-info.java
+ 
test/tools/javac/diags/examples/NotDefAccessDoesNotRead/modulesourcepath/impl/impl/Impl.java
+ 
test/tools/javac/diags/examples/NotDefAccessDoesNotRead/modulesourcepath/impl/module-info.java
+ 
test/tools/javac/diags/examples/NotDefAccessDoesNotReadFromUnnamed/NotDefAccessDoesNotReadFromUnnamed.java
+ 
test/tools/javac/diags/examples/NotDefAccessDoesNotReadFromUnnamed/modulepath/api/api/Api.java
+ 
test/tools/javac/diags/examples/NotDefAccessDoesNotReadFromUnnamed/modulepath/api/module-info.java
+ 
test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/NotDefAccessDoesNotReadUnnamed.java
+ 
test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/classpath/api/Api.java
+ 
test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/modulesourcepath/auxiliary/auxiliary/Auxiliary.java
+ 
test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/modulesourcepath/auxiliary/module-info.java
+ 
test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/modulesourcepath/impl/impl/Impl.java
+ 
test/tools/javac/diags/examples/NotDefAccessDoesNotReadUnnamed/modulesourcepath/impl/module-info.java
+ 
test/tools/javac/diags/examples/NotDefAccessNotExported/NotDefAccessNotExported.java
+ 
test/tools/javac/diags/examples/NotDefAccessNotExported/modulesourcepath/api/api/Api.java
+ 

hg: jigsaw/jake/langtools: 3 new changesets

[jonathan . gibbons]

Changeset: 3286b60836a5
Author:jjg
Date:  2016-11-03 13:35 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3286b60836a5

temporary fix to merge multiple provides for a service

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java

Changeset: 03cece156818
Author:jjg
Date:  2016-11-03 13:36 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/03cece156818

update remaining tests to use :open as needed

! test/jdk/jshell/HistoryTest.java
! test/tools/javac/6304921/TestLog.java
! test/tools/javac/modules/PatchModulesTest.java
! test/tools/javac/platform/PlatformProviderTest.java
! test/tools/javac/processing/model/TestSymtabItems.java
! test/tools/javac/scope/DupUnsharedTest.java
! test/tools/javac/scope/HashCollisionTest.java
! test/tools/javac/types/ScopeListenerTest.java

Changeset: 8f326cd2eac5
Author:jjg
Date:  2016-11-03 13:37 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8f326cd2eac5

Merge

hg: jigsaw/jake/langtools: fix remaining uses of :private

[jonathan . gibbons]

Changeset: 8154a3ab3a1f
Author:jjg
Date:  2016-11-02 14:49 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8154a3ab3a1f

fix remaining uses of :private

! test/jdk/jshell/CompletionSuggestionTest.java
! test/jdk/jshell/ComputeFQNsTest.java
! test/jdk/jshell/PipeInputStreamTest.java
! test/tools/javac/6410653/T6410653.java
! test/tools/javac/options/release/ReleaseOptionClashes.java

hg: jigsaw/jake/langtools: 4 new changesets

[jonathan . gibbons]

Changeset: 1bb329a71382
Author:jjg
Date:  2016-11-02 13:04 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1bb329a71382

fix tests that use normal and deep reflective access

! test/tools/javac/6304921/TestLog.java
! test/tools/javac/modules/PatchModulesTest.java
! test/tools/javac/platform/PlatformProviderTest.java
! test/tools/javac/processing/model/TestSymtabItems.java
! test/tools/javac/scope/DupUnsharedTest.java
! test/tools/javac/scope/HashCollisionTest.java
! test/tools/javac/types/ScopeListenerTest.java

Changeset: aaeff93be80e
Author:jjg
Date:  2016-11-02 13:21 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/aaeff93be80e

remove support for old provides table

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java

Changeset: 52c488a16f7a
Author:jjg
Date:  2016-11-02 13:22 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/52c488a16f7a

add warning and example for use of --add-opens

! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java
+ test/tools/javac/diags/examples/AddOpensIgnored.java

Changeset: 9f45830b5fae
Author:jjg
Date:  2016-11-02 14:23 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9f45830b5fae

fix JShell test using compile-time and reflective access

! test/jdk/jshell/HistoryTest.java

hg: jigsaw/jake/langtools: add no-op --add-opens option to javac

[jonathan . gibbons]

Changeset: 6f99c4e110f1
Author:jjg
Date:  2016-11-02 11:20 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6f99c4e110f1

add no-op --add-opens option to javac

! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties

Re: javac --module-source-path and --patch-module do not work together

[Jonathan Gibbons]

A variant of this problem is under consideration, which may address your 
use case.


In the meantime, the workaround is to make sure there is no evidence of 
java.base on the module source path.


-- Jon

On 11/02/2016 10:11 AM, Remi Forax wrote:

I agree with that, but that's not my use case.
I want to add/override files to java.base (an existing module) with 
--patch-module when i compile several other modules with --module-source-path, 
i think this should be allowed, otherwise it will be hard to patch the JDK and 
see the effect on several modules.

Rémi

- Mail original -

Envoyé: Mercredi 2 Novembre 2016 17:57:58
Objet: Re: javac --module-source-path and --patch-module do not work together
On 11/02/2016 09:49 AM, Remi Forax wrote:

I agree that if there is a folder java.base in the module-source-path, it should
be used but this is not the case.
Here, i want to add files to an existing modules (java.base) and those files are
in output/classes not in src.

You currently can't add files with --patch-module to a module found with
--module-source-path.

-- Jon

Re: javac --module-source-path and --patch-module do not work together

[Jonathan Gibbons]

On 11/02/2016 09:49 AM, Remi Forax wrote:

I agree that if there is a folder java.base in the module-source-path, it 
should be used but this is not the case.
Here, i want to add files to an existing modules (java.base) and those files 
are in output/classes not in src.


You currently can't add files with --patch-module to a module found with 
--module-source-path.


-- Jon

Re: javac --module-source-path and --patch-module do not work together

[Jonathan Gibbons]

Remi,

Your command line is questionable for putting output/modules on both -d 
and --module-path.   You don't need it on --module-path. When compiling 
modules, javac will automatically look in the output directory for 
classes for the module(s) being compiled.


Does your module source path contain source code for java.base? If so, 
it will only use that definition of java.base, and not anything in the 
paths given with --patch-module.


-- Jon


On 11/2/16 7:14 AM, Remi Forax wrote:

Hi Jon, hi all,

When i try to compile a module with --module-source-path that uses a patched 
class (with --patch-module),
it fails.

With:
javac --module-source-path src \
   -d output/modules/ \
   --patch-module java.base=output/classes \
   --module-path output/modules \
   $(find src/org.hibernate.jpa/ -name "*.java")

it seems that javac tries to find the source of the patched module (here 
java.base) in the module-source-path,
so it get this error

error: cannot find module: java.base
1 error

I believe this is a bug.

Step to reproduce it:
git clone g...@github.com:forax/access-broker.git
and uncomment the lines that uses --module-source-path and --patch-module 
java.base=output/classes in the build.sh.

regards,
Rémi

hg: jigsaw/jake/langtools: fix test for provides table

[jonathan . gibbons]

Changeset: 74b4b6a2ae2b
Author:jjg
Date:  2016-10-31 16:50 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/74b4b6a2ae2b

fix test for provides table

! test/tools/javac/classfiles/attributes/Module/ModuleTest.java
! test/tools/javac/classfiles/attributes/Module/ModuleTestBase.java

hg: jigsaw/jake/langtools: initial support for new provides syntax and provides table in Module attribute

[jonathan . gibbons]

Changeset: 08e003561fba
Author:jjg
Date:  2016-10-31 16:00 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/08e003561fba

initial support for new provides syntax and provides table in Module attribute

! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java
! src/jdk.compiler/share/classes/com/sun/source/tree/ProvidesTree.java
! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java
! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Module_attribute.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
! src/jdk.jdeps/share/classes/module-info.java
! test/tools/javac/modules/AnnotationProcessing.java
! test/tools/javac/modules/RepeatedUsesAndProvidesTest.java

hg: jigsaw/jake/jdk: basic support for new provides table in Module attribute

[jonathan . gibbons]

Changeset: 9fcb953ee79d
Author:jjg
Date:  2016-10-31 15:59 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9fcb953ee79d

basic support for new provides table in Module attribute

! src/java.base/share/classes/java/lang/module/ModuleInfo.java
! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java

hg: jigsaw/jake/langtools: update javac tests

[jonathan . gibbons]

Changeset: 2fb22956b1d1
Author:jjg
Date:  2016-10-31 15:22 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2fb22956b1d1

update javac tests

+ 
test/tools/javac/diags/examples/HasBeenDeprecatedRemovalModule/HasBeenDeprecatedRemovalModule.java
+ 
test/tools/javac/diags/examples/HasBeenDeprecatedRemovalModule/modulesourcepath/m1/module-info.java
+ 
test/tools/javac/diags/examples/HasBeenDeprecatedRemovalModule/modulesourcepath/m2/module-info.java
+ test/tools/javac/modules/OpenModulesTest.java
- test/tools/javac/modules/WeakModulesTest.java

hg: jigsaw/jake/langtools: 17 new changesets

[jonathan . gibbons]

Changeset: 0a91e3198c97
Author:jlahoda
Date:  2016-10-18 16:00 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0a91e3198c97

8167461: jshell tool: Scanner#next() hangs tool
Summary: PipeInputStream.read(byte[]...) should only read available bytes; 
properly resending exceptions for snippet's System.in and properly closing it; 
more reliable way to cancel user input while waiting in System.in.
Reviewed-by: rfield

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/IOContext.java
! src/jdk.jshell/share/classes/jdk/jshell/JShell.java
! src/jdk.jshell/share/classes/jdk/jshell/execution/PipeInputStream.java
! src/jdk.jshell/share/classes/jdk/jshell/execution/Util.java
! test/jdk/jshell/KullaTesting.java
+ test/jdk/jshell/PipeInputStreamTest.java
! test/jdk/jshell/UserInputTest.java

Changeset: 3fc90eaaf922
Author:vromero
Date:  2016-03-02 18:25 -0500
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3fc90eaaf922

8026721: Enhance Lambda serialization
Reviewed-by: jjg, briangoetz

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
+ test/tools/javac/T8029102/WarnSerializableElementTest.java
+ test/tools/javac/T8029102/WarnSerializableElementTest.out
- test/tools/javac/T8029102/WarnSerializableLambdaTest.java
- test/tools/javac/T8029102/WarnSerializableLambdaTest.out
! test/tools/javac/T8029102/WarnSerializableLambdaTestb.java
! test/tools/javac/T8029102/WarnSerializableLambdaTestb.out
+ test/tools/javac/T8029102/WarnSerializableLambdaTestc.java
+ test/tools/javac/T8029102/WarnSerializableLambdaTestc.out
! test/tools/javac/diags/CheckResourceKeys.java
! test/tools/javac/diags/examples.not-yet.txt
! test/tools/javac/diags/examples/WarnSerializableLambda.java

Changeset: 69db08651f8f
Author:bpatel
Date:  2016-07-14 13:35 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/69db08651f8f

8151921: Improved page resolution
Reviewed-by: jjg, ksrini, ahgross

! 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlWriter.java
! test/com/sun/javadoc/testJavascript/TestJavascript.java
! test/jdk/javadoc/doclet/testJavascript/TestJavascript.java

Changeset: d02323f750f6
Author:jlahoda
Date:  2016-10-19 12:42 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d02323f750f6

8166183: jshell tool: on return from Ctrl-Z, garbage on screen, dies with Ctrl-C
Summary: Reset the console when the process is suspended and resumed.
Reviewed-by: rfield

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java

Changeset: b6f22cf3714e
Author:tbell
Date:  2016-10-19 07:48 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b6f22cf3714e

8167600: jib make run-test for langtools and intermittent failures on 
windows-x86
Reviewed-by: ihse

! test/Makefile

Changeset: 96a5248fbf04
Author:ksrini
Date:  2016-10-19 14:51 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/96a5248fbf04

8167383: Javadoc does not handle packages correctly when used with module 
option.
Reviewed-by: bpatel, jjg

! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java
! test/jdk/javadoc/tool/modules/FilterOptions.java
! test/jdk/javadoc/tool/modules/Modules.java
! test/tools/lib/toolbox/JavadocTask.java

Changeset: aa4a8d0a818a
Author:ksrini
Date:  2016-10-19 16:58 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/aa4a8d0a818a

8168368: Add missing bug id for JDK-8167383
Reviewed-by: bpatel

! test/jdk/javadoc/tool/modules/FilterOptions.java

Changeset: 2a3e23ee1b65
Author:rfield
Date:  2016-10-20 12:53 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2a3e23ee1b65

8163840: jshell tool: provide way to display configuration settings
Reviewed-by: jlahoda

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ArgTokenizer.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Feedback.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/MessageHandler.java
! 
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties
! test/jdk/jshell/CommandCompletionTest.java
! test/jdk/jshell/ExternalEditorTest.java
! test/jdk/jshell/ToolBasicTest.java
! test/jdk/jshell/ToolCommandOptionTest.java
! 

Re: --module-source-path option implementation in javac

[Jonathan Gibbons]

Currently, the compiler expects sources on a source path (i.e. 
--source-path) to be organized in a specific hierarchy corresponding to 
packages and classes.   For the module source path, this is extended to 
include the enclosing module.  Although we experimented with requiring 
the module directory to be immediately enclosing the package directory, 
this proved to be too onerous in practice, and we weakened the 
requirement to be that the sources for a module should be in one or more 
directories below a directory named for the module.  The use case is for 
complex projects that have variant forms of the source code for a 
module, such as baseline shared code, and OS-specific variants, such as 
you find in OpenJDK itself.


This means that the each element on the module source path is composed 
of 3 parts:
1. one or more paths identify the paths to the directories 
containing module directories

2. a directory named for the module
3. one or more paths identifying the subdirectories containing 
roots of the package hierarchies for the module's classes.


Thus, the '*' you see in the module path should not be construed as a 
wildcard, so much as it is a token to indicate where in the overall path 
the module name is expected to appear.


The 3rd component may be empty, in which case you can drop the second 
component as well; it will be inferred to be at the end of the given paths.


Here are some examples of how this can be used.

If your project has a couple of modules m1, m2, the simplest 
organization is to have a src/ directory, and put the source for m1 in 
src/m1/ and the source for m2 in src/m2/.  If you do that, your module 
source path could be like

--module-source-path /Users/Me/MyProject/src
The compiler will be able to find everything it needs in this simple 
case under the src/ directory.  If it needs to find class p1.C1 in m1 it 
can look in /Users/Me/MyProject/src/m1/p1/C1.java, etc.


Now suppose the project is a bit more complicated, and each module has 
some OS-specific code and some OS-independent code.  You might want to 
put the Linux code in src/m1/linux, the Windows code in src/m1/windows, 
and the shared code in src/m1/shared, and ditto for m2.   You can tell 
the compiler about that using a mdule source path like one of these:

--module-source-path /Users/Me/MyProject/src/*/{linux,shared}
--module-source-path /Users/Me/MyProject/src/*/{windows,shared}

Now, maybe the project gets even bigger, and you start generating some 
of the code for each module.  You generate the code for m1 in 
build/gensrc/m1, and the code for m2 in build/gensrc/m2.   You can 
describe that too:
--module-source-path 
/Users/Me/MyProject/src/*/{linux,shared}:/Users/Me/MyProject/build/gensrc/*


At this point, it is important to realize that * is more than a 
wildcard. It stands for the same module name in all the places it 
appears.In other words, the source for m1 will be found in

/Users/Me/MyProject/src/m1/{linux,shared}:/Users/Me/MyProject/build/gensrc/m1
and the source for m2 will likewise be found in
/Users/Me/MyProject/src/m2/{linux,shared}:/Users/Me/MyProject/build/gensrc/m2

Yes, this is complicated, but so is the use case.   I go back to saying 
that the simple case is simple:   if you arrange the code in your 
modules such that you put the code for a module in an enclosing 
directory named for the module, the module source path becomes more like 
a simple path, as in

--module-source-path /Users/Me/MyProject/src
or if it is in multiple projects, use
--module-source-path 
/Users/Me/MyProject/src:/Users/Me/MyOtherProject/src


The requirement that the source must be in/under a directory named for 
the module is a natural extension of the existing naming conventions for 
the directories and files that contain packages and classes.



Addition responses inline.



On 10/18/2016 12:09 AM, Eugene Zhuravlev wrote:

Hi dev. list members,

We at JetBrains are working on jigsaw-related javac features support 
in IntelliJ IDEA. Namely, the --module-source-path parameter.
This option is important when multiple modules are compiled at the 
same time. While the IDE compiles modules one-by-one, there are 
certain situations where we have to use multi-module compilation. For 
example, the case when module-info files for different modules 
reference each other:


module-info.java in module A:
module a {
  exports a to b;
}


module-info.java in module B:
module b {
  requires a;
}

Here we have to compile sources for module A and module B together in 
one compile session and use --module-source-path parameter so that 
javac is able to resolve both module descriptors.


My recent investigations show that current javac implementation 
assumes certain disk layout for the source files that form a module. 
This leads to restrictions on the --module-source-path argument value. 
Currently this value is a list of paths where every path may 
optionally a "*" wildcard denoting any 

hg: jigsaw/jake/langtools: fix 'requires public' in diagnostic to 'requires transitive'

[jonathan . gibbons]

Changeset: 9d791b717b5c
Author:jjg
Date:  2016-10-19 13:58 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9d791b717b5c

fix 'requires public' in diagnostic to 'requires transitive'

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
- 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/LeaksNotAccessibleNotRequiredPublic.java
- 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/modulesourcepath/m1/api1/Api1.java
- 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/modulesourcepath/m1/module-info.java
- 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/modulesourcepath/m2/api2/Api2.java
- 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/modulesourcepath/m2/module-info.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredTransitive/LeaksNotAccessibleNotRequiredTransitive.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredTransitive/modulesourcepath/m1/api1/Api1.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredTransitive/modulesourcepath/m1/module-info.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredTransitive/modulesourcepath/m2/api2/Api2.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredTransitive/modulesourcepath/m2/module-info.java
! test/tools/javac/modules/ExportsUnexported.java

Re: Review Request: JDK-8166860 Add magic number to jmod file

[Jonathan Gibbons]

Langtools change looks good,

-- Jon

On 09/30/2016 09:29 PM, Mandy Chung wrote:

Jon points out that javac should also be updated.  javac currently opens the 
JMOD file with JarFileSystem.  Jon and I discussed this and we agree to keep 
the current workaround for now and add the validation to detect if the JMOD 
file is valid.

Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8166860/webrev.02/

The jdk change is the same as webrev.01.  The only change is in langtools repo.

Mandy


On Sep 28, 2016, at 9:56 PM, Mandy Chung  wrote:

Webrev:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8166860/webrev.00/index.html

The change adds a magic number in jmod file to enable future revision of the 
JMOD format. It's currently a zip file and may change in a future release.  
JmodFile opens the file to validate the magic header and version.  Module path, 
module reader, jlink are updated in this patch.  This implementation opens zip 
file as well to support look up of a named entry.  There isn’t any simple way 
to avoid opening the jmod file twice unless it digs into the ZipFile internals. 
 Since jmod is not performance critical (not supported at runtime) and pure 
Java modules can be packaged as modular JARs, I go with this approach and can 
look into it when this becomes a real issue.

Mandy

Re: Maven annotation processing fails with JDK9-ea+138

[Jonathan Gibbons]

If the annotation processor is trying to execute code in that module, 
you may want -J--add-modules=java.xml.bind to add the module to the 
javac runtime environment, as compared to the compilation environment


-- Jon


On 10/4/16 11:48 AM, Stephen Felts wrote:

In JDK9, the java.xml.bind module is hidden by default.
You can normally turn it on by specifying --add-modules=java.xml.bind


-Original Message-
From: Christian Beikov [mailto:christian.bei...@gmail.com]
Sent: Tuesday, October 04, 2016 2:22 PM
To: jigsaw-dev@openjdk.java.net
Subject: Maven annotation processing fails with JDK9-ea+138

Hello,

I have been trying out to build one of my Maven projects with JDK
9-ea+138 and it failed.
Specifically I got java.lang.NoClassDefFoundError:
javax/xml/bind/JAXBException during annotation processing.

I am using the org.bsc.maven:maven-processor-plugin:2.2.4 and the annotation 
processor is the hibernate metamodel generator.
Is this a known issue or am I missing some configuration?

Regards,
Christian

Re: Java 9 EA 136 error

[Jonathan Gibbons]

On 09/20/2016 07:49 AM, Alan Bateman wrote:

On 20/09/2016 06:43, Stephen Colebourne wrote:


Just to note that the report below is mostly about the confusing error
message, something which users will get if they write "wek" instead of
"weak".

Understood, I'm sure Jon or Jan will comment on that.


Stephen,

Thanks for the report. Filed as
https://bugs.openjdk.java.net/browse/JDK-8166420

-- Jon





(I've downloaded the correct build now and it has the same
error message issue)

What does `java -version` show? I ask because "weak module myapp { }" 
should compile with the EA builds.


-Alan

Re: Review Request: JDK-8160851: Remove old module-related options

[Jonathan Gibbons]

Looks good to me.

-- Jon

On 08/26/2016 04:06 PM, Mandy Chung wrote:

This patch removes the old module options from java, javac, javadoc, etc.  The 
new options are in jdk-9+132 [1].  I did a scan on the jdk9/dev forest to 
replace any remaining reference to the old options.  I find some tests in 
jdk9/hs/hotspot using the old options that I will file a separate issue.

Webrev at:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160851/webrev.00/index.html

Mandy
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-August/009025.html

hg: jigsaw/jake/langtools: 20 new changesets

[jonathan . gibbons]

Changeset: 0f8b6aba6279
Author:ksrini
Date:  2016-08-09 07:31 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0f8b6aba6279

8075529: Documentation in DocumentationTool.getTask(...) should mention about 
"null" parameter for doclet.
Reviewed-by: jjg

! src/java.compiler/share/classes/javax/tools/DocumentationTool.java

Changeset: d7aa2b610144
Author:jlahoda
Date:  2016-08-09 20:27 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d7aa2b610144

8143048: Re-examine dependency on property sun.boot.class.path
Summary: Removing obsolete references to sun.boot.class.path
Reviewed-by: jjg

! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java
! test/tools/javac/processing/messager/MessagerDiags.java

Changeset: 99470b5ea8d8
Author:jjg
Date:  2016-08-09 13:22 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/99470b5ea8d8

8160697: HTMLWriter needs perf cleanup
Reviewed-by: ksrini, bpatel

! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractModuleIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractPackageIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeFieldWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConfigurationImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java
+ 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FrameOutputWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModulePackageIndexFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java
! 

Re: Another clarification on module source spread across multiple locations

[Jonathan Gibbons]

On 08/18/2016 05:17 AM, Alan Bateman wrote:

On 11/08/2016 05:50, Jayaprakash Arthanareeswaran wrote:


Hi Alan,
I also need a clarification on the following passage in JEP 261:
/"In large systems the source code for a particular module may be 
spread across several different directories. In the JDK itself 
, e.g., the source files for a 
module may be found in any one of the directories 
|src//share/classes|, |src///classes|, or 
|build/gensrc/|, where || is the name of the target 
operating system. To express this in a module source path while 
preserving module identities we allow each element of such a path to 
use braces (|{| and |}|) to enclose commas-separated lists of 
alternatives and a single asterisk (|*|) to stand for the module 
name. The module source path for the JDK can then be written as/

/|{src/*/{share,}/classes,build/gensrc/*}|"/
While the first sentence states spread across several directories, 
later on it states ' /may be found in any _one_ of the directories/'. 
Does "any one of" really mean "any of" ?
Can you please confirm that it is indeed possible to specify multiple 
directories at once for a specific module.


Jon would be the best person to answer this but "yes", the module 
source path specify multiple directories using this syntax. That is, 
the source code for a module may be in distinct directories. We have 
this in the JDK because there are platform specific classes, also a 
lot of source code generated at build time.


-Alan


It means "any of".  Once a module has been determined to be on the 
module source path (as compared to any of the other module paths), the 
sources for the module may appear in any of the appropriate directories 
on the module source path. For any particular source file, "first one 
wins", meaning that the items listed on the module source path are 
checked in order, in the same way that javac searches a regular source path.


-- Jon

hg: jigsaw/jake/langtools: 18 new changesets

[jonathan . gibbons]

Changeset: 8150eeaf8c24
Author:vromero
Date:  2016-07-27 07:07 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8150eeaf8c24

8161277: javax.lang.model.util.Types.isSameType(...) returns true on wildcards
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacTypes.java
+ test/tools/javac/T8161277/IsSameTypeWildcardTest.java
! test/tools/lib/types/TypeHarness.java

Changeset: b4e9df9d2f31
Author:sadayapalam
Date:  2016-07-28 10:13 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b4e9df9d2f31

8158224: NullPointerException in 
com.sun.tools.javac.comp.Modules.checkCyclicDependencies when module missing
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java
+ test/tools/javac/modules/T8158224/Processor.java
+ test/tools/javac/modules/T8158224/T8158224.java
+ test/tools/javac/modules/T8158224/T8158224.out
+ test/tools/javac/modules/T8158224/mods/foo/module-info.java

Changeset: e978c992b81f
Author:amurillo
Date:  2016-07-28 16:44 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e978c992b81f

Merge


Changeset: 467ad69d5948
Author:ksrini
Date:  2016-07-20 12:49 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/467ad69d5948

8154705: invalid use of ALL-MODULE-PATH causes crash
Summary: Introducing Modules.initModules as a clear point where the module 
graphs is initialized in javac
Reviewed-by: jjg, ksrini

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/JavadocTool.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocTool.java
! test/tools/javac/6330997/T6330997.java
! test/tools/javac/T6435291/T6435291.java
! test/tools/javac/api/6400303/T6400303.java
! test/tools/javac/api/TestResolveIdent.java
! test/tools/javac/defaultMethods/BadClassfile.java
! test/tools/javac/lib/combo/ReusableContext.java
! test/tools/lib/types/TypeHarness.java

Changeset: 74dd68a85107
Author:ddehaven
Date:  2016-07-29 09:35 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/74dd68a85107

8161544: JDK9 message drop 20 resource updates - OpenJDK
Summary: JDK9 message drop 20 resource updates - openjdk
Reviewed-by: rfield, peytoia
Contributed-by: li.ji...@oracle.com

! 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_zh_CN.properties
! 
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_ja.properties

Changeset: 653c218a6e57
Author:sdrach
Date:  2016-07-29 12:27 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/653c218a6e57

8143366: Control characters in constant pool strings are not escaped properly
Reviewed-by: jjg

! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/ConstantWriter.java
+ test/tools/javap/ControlCharTest.java

Changeset: 3665ebc22a42
Author:vromero
Date:  2016-08-01 08:36 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3665ebc22a42

8161708: javac, consider a different way to handle access code for operators
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Operators.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java

Changeset: a8dde57edb12
Author:bpatel
Date:  2016-08-02 13:14 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a8dde57edb12

8154817: Fix the click-through navigation for modules
Reviewed-by: jjg, ksrini

! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java
+ 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlAttr.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlDocWriter.java
!