Re: Review request: JDK-8172870 test/tools/jmod/JmodTest.java fails on windows with AccessDeniedException

[Alan Bateman]

On 17/01/2017 21:23, Mandy Chung wrote:


This test case attempts to verify that the temp file created by jmod is cleaned 
up and removed if jmod create command fails.  It first cleans up any temp files 
matching the prefix and suffix created for this test case.  The test fails 
because the fix for JDK-8160286 that creates the jmod temp file in the tmp 
directory and it was updated to use Files.walk that may fail to read the file 
attributes if the user doesn’t have access.

The patch fixes the test to call Files.list and find only the writeable files 
matching the prefix and suffix.

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172870/webrev.00/


This looks okay (somewhat odd test but okay).

-Alan

Re: RFR 8168254: Detect duplicated resources in packaged modules

[Mandy Chung]

> On Jan 17, 2017, at 10:03 PM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8168254/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8168254

Looks good except the copyright end year.

Mandy

RFR 8168254: Detect duplicated resources in packaged modules

[Sundararajan Athijegannathan]

Please review http://cr.openjdk.java.net/~sundar/8168254/webrev.00/ for 
https://bugs.openjdk.java.net/browse/JDK-8168254


Thanks,
-Sundar

Re: Fwd: resource location problem in JDK 9 from build 148 onward

[Rick Hillegas]

Thanks, David and Alan. The suggested workaround works for me. I will 
mouse your response into the commentary on 
https://issues.apache.org/jira/browse/DERBY-6856, where I have been 
collecting all of the issues I've encountered when building and testing 
Apache Derby with JDK 9.


I strongly recommend a GA release note about this topic if the 
backward-incompatibility won't be ameliorated.


Thanks,
-Rick


On 1/16/17, 5:15 PM, David Holmes wrote:

Hi Rick,



On 17/01/2017 10:55 AM, Rick Hillegas wrote:

Resending since the moderator rejected my initial post for want of a
subscription to jigsaw-dev.

 Original Message 
Subject: resource location problem in JDK 9 from build 148 onward
Date: Mon, 16 Jan 2017 08:45:23 -0800
From: Rick Hillegas 
To: jigsaw-dev@openjdk.java.net, "derby-...@db.apache.org"




Dalibor Topic suggested that I pose this question to the jigsaw-dev 
list:


Starting (at least) with build 148, resource location has changed in a
way which is not backward compatible with JDK 8. The following
experiment shows the behavior change:

1) Compile the following class using JDK 8 and put it in a jar file
called z.jar:

public class public class ResourceLocationProblem
{
  public static void main(String... args) throws Exception
  {
String resourceName = "/META-INF/MANIFEST.MF";
Class dummyClass = (new Object()).getClass();
Object is = dummyClass.getResourceAsStream(resourceName);

if (is != null) { System.out.println("Resource found."); }
else { System.out.println("Resource NOT found!"); }
  }
}

2) Then run the program thusly:

  java -cp z.jar ResourceLocationProblem

On JDK 8, the program produces this output...

Resource found.

...while on JDK 9 build 151 the program produces this output...

Resource NOT found!

Dalibor pointed me to the following proposal, which indicates that some
significant changes have been made to resource location:
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000392.html 



However, I am not trying to use any jigsaw features. This test program
suggests that JDK 9 will break many legacy applications.

1) Is the observed behavior change a bug?


No. Modules enforce strong encapsulation of types and resources. As 
per the link you were given:


  - The `Class::getResource*` methods, when invoked upon a class defined
in a named module, only locate resources from within that module.
These methods are also caller-sensitive.

So you are using Object.class is the named java.base module to try and 
find local resources in the unnamed-module, that are in z.jar. That 
won't work.



2) What is the recommended workaround?


Use a Class object from the "module" that contains the resource i.e. 
ResourceAllocationProblem.class in your example.


David
-


Thanks,
-Rick

hg: jigsaw/jake/langtools: jdeps update per ModuleDescriptor/Builder cleanup

[mandy . chung]

Changeset: 2eac819e2faa
Author:mchung
Date:  2017-01-17 14:42 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2eac819e2faa

jdeps update per ModuleDescriptor/Builder cleanup

! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java

Review request: JDK-8172870 test/tools/jmod/JmodTest.java fails on windows with AccessDeniedException

[Mandy Chung]

This test case attempts to verify that the temp file created by jmod is cleaned 
up and removed if jmod create command fails.  It first cleans up any temp files 
matching the prefix and suffix created for this test case.  The test fails 
because the fix for JDK-8160286 that creates the jmod temp file in the tmp 
directory and it was updated to use Files.walk that may fail to read the file 
attributes if the user doesn’t have access.

The patch fixes the test to call Files.list and find only the writeable files 
matching the prefix and suffix.

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172870/webrev.00/

Mandy

RE: Compact profile modules

[Uwe Schindler]

Hi Alan,

> > Are only the modules removed, and the javac options are still available?
> We are compiling Apache Lucene Core using the compact1 profile currently:
> >
> >
> >
> > So we append "-profile compact1" when invoking javac. We have not
> noticed any problems when doing this with (non-jigsaw) EA build 152.
> >
> > How are the "-profile compact1" parameters being resolved now?
> >
> >
> `javac -profile compactX` can't be used with --release 9 or
> -source/-target 9. It continues to work as before with -target 8, that
> might be why you didn't notice anything.

We are compiling of course with Java 8 compatibility (Lucene is on Java 8). My 
question was more, how it works now. If the aggregator module is gone, how does 
javac figure out the profiles?

Maybe it is because we use --release 8, if it detects a Java 9 compiler (some 
handmade Ant logic does this for us) instead of -source/-target 
(https://github.com/apache/lucene-solr/blob/master/lucene/common-build.xml#L1944-L1947).
 In that case it uses the old version in ct.sym file for compiling, right? But 
how does it work with -source/-target?

Uwe

hg: jigsaw/jake/jdk: 2 new changesets

[alan . bateman]

Changeset: f92bf219c0ec
Author:alanb
Date:  2017-01-17 12:55 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f92bf219c0ec

Further clean-up of automatic module support

! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
! src/java.base/share/classes/java/lang/module/Resolver.java
! src/java.base/share/classes/java/lang/reflect/Module.java
! test/java/lang/module/AutomaticModulesTest.java
! test/java/lang/module/ModuleDescriptorTest.java

Changeset: d9e0f57b69f5
Author:alanb
Date:  2017-01-17 12:56 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d9e0f57b69f5

Fix alignment issue

! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java

Re: Compact profile modules

[Alan Bateman]

On 17/01/2017 10:07, Uwe Schindler wrote:


:
Are only the modules removed, and the javac options are still available? We are 
compiling Apache Lucene Core using the compact1 profile currently:

   

So we append "-profile compact1" when invoking javac. We have not noticed any 
problems when doing this with (non-jigsaw) EA build 152.

How are the "-profile compact1" parameters being resolved now?


`javac -profile compactX` can't be used with --release 9 or 
-source/-target 9. It continues to work as before with -target 8, that 
might be why you didn't notice anything.


-Alan

RE: Compact profile modules

[Uwe Schindler]

Hi Mandy,

> java.compact$N modules were removed in jdk-9+150 [1][2].
> 
> We revisited the need for java.compact$N aggregator.  Compact Profiles
> were useful in SE 8 but are legacy in 9, as intended from the outset.
> Highlighting them in the standard SE 9 module graph gives them
> unnecessary importance going forward. We want people who care about
> small systems to think about modules, not profiles.

Are only the modules removed, and the javac options are still available? We are 
compiling Apache Lucene Core using the compact1 profile currently:

  

So we append "-profile compact1" when invoking javac. We have not noticed any 
problems when doing this with (non-jigsaw) EA build 152.

How are the "-profile compact1" parameters being resolved now?

Uwe

> In addition, these aggregator modules are not a complete solution
> since the necessary service providers are still needed to be added
> manually for the Compact Profile builds.
> 
> Mandy
> [1] https://bugs.openjdk.java.net/browse/JDK-8171201
> [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-
> December/010561.html
> 
> > On Jan 16, 2017, at 1:35 PM, Sander Mak  wrote:
> >
> > The build I'm currently using (jigsaw-b151) doesn't contain the
> java.compactN modules anymore. Looks like this is a deliberate removal [1],
> although I can't find any reason for it. Are they permanently gone? Why?
> They made for such a nice example of implied readability in the JDK... They
> were also useful in constructing small images with jlink. As I understood
> things at JavaOne, jlink with the compact module definitions was supposed
> to be a 'migration path' from Java SE 8 embedded.
> >
> >
> > Sander
> >
> > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-
> December/010603.html

Re: RFR 8171380: Remove exports from jdk.jlink

[forax]

- Mail original -
> De: "Chris Hegarty" 
> À: "Remi Forax" 
> Cc: "jigsaw-dev" 
> Envoyé: Mardi 17 Janvier 2017 10:36:32
> Objet: Re: RFR 8171380: Remove exports from jdk.jlink

>> On 17 Jan 2017, at 00:02, Remi Forax  wrote:
>> 
>> Cris,
>> it seems that there is a mechanism for API that are experimental in the jdk,
>> by example java.net.http uses this mechanism, is it possible to reuse the 
>> same
>> mechanism for the jlink plugin API ?
> 
> I did look at the possibility exposing the JLink Plugin API through
> an incubator module, but found that it would add complication to
> the code in order to refactor out the API to the extent where regular
> plugins could co-exist with custom plugins, while not having the
> jlink module depend on the incubator module. I discussed this
> offline with the jlink folk and they seemed to think that since this
> is a niche area, having to add --add-exports to was a reasonable
> compromise at this point, rather than the potentially more invasive
> changes that would be required to use incubator modules.

Ok,
it seems i'm the only one to have played with the plugin API :)

I think you can also load jlink in an empty Layer to workaround the lack of the 
exported package, at least at runtime.

> 
> -Chris.

Rémi

Re: RFR 8171380: Remove exports from jdk.jlink

[Chris Hegarty]

> On 17 Jan 2017, at 00:02, Remi Forax  wrote:
> 
> Cris,
> it seems that there is a mechanism for API that are experimental in the jdk,
> by example java.net.http uses this mechanism, is it possible to reuse the 
> same mechanism for the jlink plugin API ?

I did look at the possibility exposing the JLink Plugin API through
an incubator module, but found that it would add complication to
the code in order to refactor out the API to the extent where regular
plugins could co-exist with custom plugins, while not having the
jlink module depend on the incubator module. I discussed this 
offline with the jlink folk and they seemed to think that since this
is a niche area, having to add --add-exports to was a reasonable
compromise at this point, rather than the potentially more invasive
changes that would be required to use incubator modules.

-Chris.

Re: Fwd: resource location problem in JDK 9 from build 148 onward

[Alan Bateman]

On 17/01/2017 00:55, Rick Hillegas wrote:


:

public class public class ResourceLocationProblem
{
  public static void main(String... args) throws Exception
  {
String resourceName = "/META-INF/MANIFEST.MF";
Class dummyClass = (new Object()).getClass();
Object is = dummyClass.getResourceAsStream(resourceName);

if (is != null) { System.out.println("Resource found."); }
else { System.out.println("Resource NOT found!"); }
  }
} 
For the example then I assume you want 
ClassLoader.getSystemResourceAsStream("META-INF/MANIFEST.MF") but as 
with the snippet on JDK 8, then there is no guarantee that it will find 
the resource in z.jar even if it's the first JAR file on the class path 
(it might locate the resource in JAR files on the boot class path or ext 
directory).


As regards the Class::getResource methods then they work exactly as 
before when invoked on a class on the class path (or more generally, any 
class that is not in a named module). This goes for input in both 
relative and absolute input. However when invoked on a class in named 
module then they locate the resource in the module. In this example then 
java.lang.Object is in the java.base module. So there is a compatibility 
issue for uses like the above where it looks like you are looking for 
the resource in module java.base. The spec could potentially be changed 
to have it fallback to the defining loader (or the system class loader 
when the defining loader is null) but that would need further 
consideration to see if it's the right thing to do or not.


-Alan