date:20170116

Re: Compact profile modules

2017-01-16 Thread Alan Bateman


On 17/01/2017 01:04, David Holmes wrote:



I would assume however that we will clearly document how to go from a 
compact profile to using jlink to produce a comparable JRE? At a 
minimum, given the compact profiles were defined at the package-level, 
we should document which modules are needed to provide the packages 
defined for a given compact profile.
Yes, there needs to be some documentation for embedded developers so 
that they can use jlink to create the (approximate) equivalent of what 
was the compact1-3 builds. Also note that the build still supports "make 
profiles" and the set of modules needed to create the compact profile 
profiles has the list of root modules needed to create these images.


-Alan

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

2017-01-16 Thread David Holmes


Typo: ResourceAllocationProblem.class -> ResourceLocationProblem.class

David

On 17/01/2017 11:15 AM, 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

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

2017-01-16 Thread David Holmes


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

Re: Compact profile modules

2017-01-16 Thread David Holmes


Hi Mandy,

On 17/01/2017 7:51 AM, Mandy Chung wrote:

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.


I would assume however that we will clearly document how to go from a 
compact profile to using jlink to produce a comparable JRE? At a 
minimum, given the compact profiles were defined at the package-level, 
we should document which modules are needed to provide the packages 
defined for a given compact profile.



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.


That sounds like it also needs further explanatory documentation.

Thanks,
David



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

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

2017-01-16 Thread Rick Hillegas

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?

2) What is the recommended workaround?

Thanks,
-Rick

Re: RFR 8171380: Remove exports from jdk.jlink

2017-01-16 Thread Remi Forax

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 ?

Rémi

- Mail original -
> De: "Chris Hegarty" 
> À: "jigsaw-dev" , "A. Sundararajan" 
> , "Jim Laskey
> (Oracle)" 
> Envoyé: Lundi 16 Janvier 2017 16:46:16
> Objet: RFR 8171380: Remove exports from jdk.jlink

> The Jlink Plugin API is not going to be supported in 9, so
> should not be exported [1], for use by third parties. Besides
> the removal of the export, most of the changes are adding
> @modules tags to existing tests.
> 
> http://cr.openjdk.java.net/~chegar/8171380.00/
> 
> Note: Sundar will follow up with 8172864 [2] to remove the
> '--plugin-module-path'. Custom plugins can be written and
> deployed on the class path using the --add-exports command
> line, if required.
> 
> This change depends on fix in jtreg b05 [3], so bumps the
> minimum required version.
> 
> -Chris.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8171380
> [2] https://bugs.openjdk.java.net/browse/JDK-8172864
> [3] http://hg.openjdk.java.net/code-tools/jtreg/rev/f79ef1ecc483

Re: Compact profile modules

2017-01-16 Thread Mandy Chung

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. 

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

Compact profile modules

2017-01-16 Thread Sander Mak

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

[ANN] Apache Maven Compiler Plugin 3.6.1 Released

2017-01-16 Thread Robert Scholte

The Apache Maven team is pleased to announce the release of the Apache  
Maven Compiler Plugin, version 3.6.1


Most important change is the support for test-compile when using JDK 9  
build b148+


https://maven.apache.org/plugins/maven-compiler-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-compiler-plugin
  3.6.1


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-compiler-plugin/download.cgi

Release Notes - Maven Compiler Plugin - Version 3.6.1

** Bug
* [MCOMPILER-282] - Remove link to non-existing Codehaus wiki
* [MCOMPILER-284] - maven.test.skip doesn't skip test compilation
* [MCOMPILER-287] - Adjust documentation module-info

** Documentation
* [MCOMPILER-281] - Remove reference to Maven 1's Java plugin

** Improvement
* [MCOMPILER-285] - Support test-compile for JDK 9 build b148+

Enjoy,

-The Apache Maven team

Re: RFR 8171380: Remove exports from jdk.jlink

2017-01-16 Thread Chris Hegarty



On 16/01/17 16:26, Alan Bateman wrote:

This looks okay except CustomPluginTest where I assume you mean to add
it to the ProblemList file.


Ok, I'll remove the @ignore and put the test on the ProblemList
before pushing.  Thanks.

-Chris.

Re: RFR 8171380: Remove exports from jdk.jlink

2017-01-16 Thread Alan Bateman




On 16/01/2017 15:46, Chris Hegarty wrote:

The Jlink Plugin API is not going to be supported in 9, so
should not be exported [1], for use by third parties. Besides
the removal of the export, most of the changes are adding
@modules tags to existing tests.

http://cr.openjdk.java.net/~chegar/8171380.00/

Note: Sundar will follow up with 8172864 [2] to remove the
'--plugin-module-path'. Custom plugins can be written and
deployed on the class path using the --add-exports command
line, if required.

This change depends on fix in jtreg b05 [3], so bumps the
minimum required version.
This looks okay except CustomPluginTest where I assume you mean to add 
it to the ProblemList file.


-Alan.

hg: jigsaw/jake/nashorn: More ModuleDescriptor/Builder cleanup

2017-01-16 Thread alan . bateman

Changeset: bf5488cc3bf9
Author:alanb
Date:  2017-01-16 15:56 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/bf5488cc3bf9

More ModuleDescriptor/Builder cleanup

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptLoader.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StructureLoader.java

Re: RFR 8171380: Remove exports from jdk.jlink

2017-01-16 Thread Sundararajan Athijegannathan


+1

-Sundar

On 16/01/17, 9:16 PM, Chris Hegarty wrote:

The Jlink Plugin API is not going to be supported in 9, so
should not be exported [1], for use by third parties. Besides
the removal of the export, most of the changes are adding
@modules tags to existing tests.

http://cr.openjdk.java.net/~chegar/8171380.00/

Note: Sundar will follow up with 8172864 [2] to remove the
'--plugin-module-path'. Custom plugins can be written and
deployed on the class path using the --add-exports command
line, if required.

This change depends on fix in jtreg b05 [3], so bumps the
minimum required version.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8171380
[2] https://bugs.openjdk.java.net/browse/JDK-8172864
[3] http://hg.openjdk.java.net/code-tools/jtreg/rev/f79ef1ecc483

hg: jigsaw/jake/langtools: More ModuleDescriptor/Builder cleanup

2017-01-16 Thread alan . bateman

Changeset: a4793508705b
Author:alanb
Date:  2017-01-16 15:57 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a4793508705b

More ModuleDescriptor/Builder cleanup

! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleExportsAnalyzer.java

hg: jigsaw/jake/jdk: More ModuleDescriptor/Builder cleanup

2017-01-16 Thread alan . bateman

Changeset: a6ec366d2a13
Author:alanb
Date:  2017-01-16 16:05 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a6ec366d2a13

More ModuleDescriptor/Builder cleanup

! src/java.base/share/classes/java/lang/module/Configuration.java
! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
! src/java.base/share/classes/java/lang/module/ModuleFinder.java
! src/java.base/share/classes/jdk/internal/misc/JavaLangModuleAccess.java
! src/java.base/share/classes/jdk/internal/module/Builder.java
! src/java.base/share/classes/jdk/internal/module/Checks.java
! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java
! src/java.base/share/classes/jdk/internal/module/ModuleInfo.java
! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java
! src/java.base/share/classes/jdk/internal/module/ModulePath.java
! src/java.base/share/classes/jdk/internal/module/Modules.java
! 
src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolConfiguration.java
! 
src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
! test/java/lang/module/AutomaticModulesTest.java
! test/java/lang/module/ConfigurationTest.java
! test/java/lang/module/ModuleDescriptorTest.java
! test/java/lang/module/ModuleFinderTest.java
! test/java/lang/module/ModuleNamesTest.java
! test/java/lang/module/ModuleReferenceTest.java
! test/java/lang/module/MultiReleaseJarTest.java
! test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java
! test/java/lang/reflect/Layer/BasicLayerTest.java
! test/java/lang/reflect/Layer/LayerAndLoadersTest.java
! test/java/lang/reflect/Layer/LayerControllerTest.java
! test/java/security/modules/ModularTest.java
! test/jdk/modules/etc/VerifyModuleDelegation.java
! test/tools/jlink/JLinkNegativeTest.java

hg: jigsaw/jake/hotspot: More ModuleDescriptor/Builder cleanup

2017-01-16 Thread alan . bateman

Changeset: 8e94614e5fd4
Author:alanb
Date:  2017-01-16 15:57 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8e94614e5fd4

More ModuleDescriptor/Builder cleanup

! test/runtime/modules/AccessCheck/CheckRead.java
! test/runtime/modules/AccessCheck/DiffCL_CheckRead.java
! test/runtime/modules/AccessCheck/DiffCL_ExpQualOther.java
! test/runtime/modules/AccessCheck/DiffCL_ExpQualToM1.java
! test/runtime/modules/AccessCheck/DiffCL_ExpUnqual.java
! test/runtime/modules/AccessCheck/DiffCL_PkgNotExp.java
! test/runtime/modules/AccessCheck/DiffCL_Umod.java
! test/runtime/modules/AccessCheck/DiffCL_UmodUpkg.java
! test/runtime/modules/AccessCheck/ExpQualOther.java
! test/runtime/modules/AccessCheck/ExpQualToM1.java
! test/runtime/modules/AccessCheck/ExpUnqual.java
! test/runtime/modules/AccessCheck/ExportAllUnnamed.java
! test/runtime/modules/AccessCheck/PkgNotExp.java
! test/runtime/modules/AccessCheck/Umod.java
! test/runtime/modules/AccessCheck/UmodDiffCL_ExpQualOther.java
! test/runtime/modules/AccessCheck/UmodDiffCL_ExpUnqual.java
! test/runtime/modules/AccessCheck/UmodDiffCL_PkgNotExp.java
! test/runtime/modules/AccessCheck/UmodUPkg.java
! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_ExpQualOther.java
! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_NotExp.java
! test/runtime/modules/AccessCheck/UmodUpkg_ExpQualOther.java
! test/runtime/modules/AccessCheck/UmodUpkg_NotExp.java
! test/runtime/modules/AccessCheck/Umod_ExpQualOther.java
! test/runtime/modules/AccessCheck/Umod_ExpUnqual.java
! test/runtime/modules/AccessCheck/Umod_PkgNotExp.java
! test/runtime/modules/ModuleHelper.java
! test/runtime/modules/ModuleStress/ModuleNonBuiltinCLMain.java
! test/runtime/modules/ModuleStress/ModuleSameCLMain.java
! test/serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java

hg: jigsaw/jake/jaxp: More ModuleDescriptor/Builder cleanup

2017-01-16 Thread alan . bateman

Changeset: 84cfa748d9d0
Author:alanb
Date:  2017-01-16 15:57 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/84cfa748d9d0

More ModuleDescriptor/Builder cleanup

! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java

RFR 8171380: Remove exports from jdk.jlink

2017-01-16 Thread Chris Hegarty


The Jlink Plugin API is not going to be supported in 9, so
should not be exported [1], for use by third parties. Besides
the removal of the export, most of the changes are adding
@modules tags to existing tests.

http://cr.openjdk.java.net/~chegar/8171380.00/

Note: Sundar will follow up with 8172864 [2] to remove the
'--plugin-module-path'. Custom plugins can be written and
deployed on the class path using the --add-exports command
line, if required.

This change depends on fix in jtreg b05 [3], so bumps the
minimum required version.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8171380
[2] https://bugs.openjdk.java.net/browse/JDK-8172864
[3] http://hg.openjdk.java.net/code-tools/jtreg/rev/f79ef1ecc483

Re: RFR 8172422: jarsigner needs to understand -?

2017-01-16 Thread Alan Bateman




On 16/01/2017 01:41, Weijun Wang wrote:

Please review the code change at

   http://cr.openjdk.java.net/~weijun/8172529/webrev.02

The validator is updated to be a PKIXValidator of the 
Validator.VAR_CODE_SIGNING variant. In order to have the same output 
message and exit code as before, the ValidatorException thrown when 
validation fails is suppressed when there are existing error flags for 
several reasons.


*jigsaw-dev*: The following change is made in java.base/module-info.java:

+exports sun.security.validator to
+jdk.jartool;
That part looks okay to me although at some point we need to go over 
every one of these qualified exports with a view to removing as many of 
possible.


-Alan

Re: Compact profile modules

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

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

Re: Compact profile modules

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

Re: RFR 8171380: Remove exports from jdk.jlink

Re: Compact profile modules

Compact profile modules

[ANN] Apache Maven Compiler Plugin 3.6.1 Released

Re: RFR 8171380: Remove exports from jdk.jlink

Re: RFR 8171380: Remove exports from jdk.jlink

hg: jigsaw/jake/nashorn: More ModuleDescriptor/Builder cleanup

Re: RFR 8171380: Remove exports from jdk.jlink

hg: jigsaw/jake/langtools: More ModuleDescriptor/Builder cleanup

hg: jigsaw/jake/jdk: More ModuleDescriptor/Builder cleanup

hg: jigsaw/jake/hotspot: More ModuleDescriptor/Builder cleanup

hg: jigsaw/jake/jaxp: More ModuleDescriptor/Builder cleanup

RFR 8171380: Remove exports from jdk.jlink

Re: RFR 8172422: jarsigner needs to understand -?

19 matches

Site Navigation

Mail list logo

Footer information