hg: jigsaw/jake/jdk: 3 new changesets

[alan . bateman]

Changeset: b057c9fbbf47
Author:alanb
Date:  2017-01-23 17:59 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b057c9fbbf47

Improve javadoc for getResourceAsStream

! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/reflect/Module.java

Changeset: 0d52f0d9a552
Author:alanb
Date:  2017-01-23 18:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0d52f0d9a552

privateLookupIn does not check that unnamed modules are readable

! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! test/java/lang/invoke/MethodHandles/privateLookupIn/Driver.java
+ test/java/lang/invoke/MethodHandles/privateLookupIn/Unnamed.java
! 
test/java/lang/invoke/MethodHandles/privateLookupIn/test/p/PrivateLookupInTests.java

Changeset: 95b225fbbe48
Author:alanb
Date:  2017-01-23 18:50 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/95b225fbbe48

Minor improvements to Layer javadoc

! src/java.base/share/classes/java/lang/reflect/Layer.java

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: Review Request: JDK-8173096 jmod files are not world-readable

[Chris Hegarty]

On 21/01/17 02:32, Mandy Chung wrote:

Updated webrev to put the temporary file in the same containing directory of 
the target file:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173096/webrev.01


Looks fine. Trivially, the test can now drop "-Djava.io.tmpdir=." .

-Chris.


I want to fix this regression in jdk-9+154.  We can revisit the approach after 
this fix if necessary.

Mandy


On Jan 20, 2017, at 8:55 AM, Mandy Chung  wrote:

Webrev:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173096/webrev.00/index.html

A recent change in jmod tool [1] creates the JMOD file with no group
and other readable permission as that’s the default permission when
creating a temporary file with Files::createTempFile.  This fixes
the permission issue by creating the JMOD file in a temporary directory.

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