requires public for automatic modules

[Paul Bakker]

Hello,

I'm experimenting with automatic modules again. I have a module "demonstrator" 
that uses Jackson Databind.

import com.fasterxml.jackson.databind.ObjectMapper;

ObjectMapper mapper = new ObjectMapper(); 
String json = mapper.writeValueAsString(modularityBook); 

In module-info.java I have the following:

requires jackson.databind;

On the modulepath I have jackson.core, jackson.databind and jackson.annotations.
Building results in an error:

 class file for com.fasterxml.jackson.core.Versioned not found

This makes sense because the ObjectMapper class that I'm using implements the 
Versioned interface (from jackson.core).
When generating a module-info.java using jdeps for the jackson.databind JAR 
however, it generates the following:

requires public jackson.annotations; 
requires public jackson.core;

This is much closer to what I would expect when using the jackson.databind 
module.
When using jackson.databind as an automatic module, I will end up with a list 
of requires for transitive dependencies that I shouldn't have to care about.
Why don't automatic modules take better care of transitive dependencies, so 
that the application's module-info looks similar to what it would after 
transforming the dependencies to named modules?

Also, jdeps doesn't actually show this problem when looking at the code when 
still on the classpath:

jdeps -cp lib/jackson-databind-2.7.3.jar 
out/com/javamodularity/demonstrator/Demo.class

Demo.class -> lib/jackson-databind-2.7.3.jar
Demo.class -> java.base
   com.javamodularity.demonstrator (Demo.class)
  -> com.fasterxml.jackson.databind 
jackson-databind-2.7.3.jar
  -> java.io
  -> java.lang

Best regards,

Paul Bakker

Re: requires public for automatic modules

[Remi Forax]

Hi Paul,

- Mail original -
> De: "Paul Bakker" 
> À: jigsaw-dev@openjdk.java.net
> Envoyé: Vendredi 22 Avril 2016 10:52:23
> Objet: requires public for automatic modules
> 
> Hello,
> 
> I'm experimenting with automatic modules again. I have a module
> "demonstrator" that uses Jackson Databind.
> 
>   import com.fasterxml.jackson.databind.ObjectMapper;
>   
>   ObjectMapper mapper = new ObjectMapper();
>   String json = mapper.writeValueAsString(modularityBook);
> 
> In module-info.java I have the following:
> 
>   requires jackson.databind;
> 
> On the modulepath I have jackson.core, jackson.databind and
> jackson.annotations.
> Building results in an error:
>   
>class file for com.fasterxml.jackson.core.Versioned not found
> 
> This makes sense because the ObjectMapper class that I'm using implements the
> Versioned interface (from jackson.core).
> When generating a module-info.java using jdeps for the jackson.databind JAR
> however, it generates the following:
> 
>   requires public jackson.annotations;
>   requires public jackson.core;
> 
> This is much closer to what I would expect when using the jackson.databind
> module.
> When using jackson.databind as an automatic module, I will end up with a list
> of requires for transitive dependencies that I shouldn't have to care about.
> Why don't automatic modules take better care of transitive dependencies, so
> that the application's module-info looks similar to what it would after
> transforming the dependencies to named modules?
> 

because it will require the runtime to parse the bytecode of an automatic 
module, which is a slow operation.

> Also, jdeps doesn't actually show this problem when looking at the code when
> still on the classpath:
> 
>   jdeps -cp lib/jackson-databind-2.7.3.jar
>   out/com/javamodularity/demonstrator/Demo.class
>   
>   Demo.class -> lib/jackson-databind-2.7.3.jar
>   Demo.class -> java.base
>  com.javamodularity.demonstrator (Demo.class)
> -> com.fasterxml.jackson.databind
> jackson-databind-2.7.3.jar
> -> java.io
> -> java.lang
> 
> Best regards,
> 
> Paul Bakker
> 
> 
> 

regards,

Rémi

hg: jigsaw/jake/langtools: 8 new changesets

[alan . bateman]

Changeset: 73717a51063b
Author:rfield
Date:  2016-04-12 22:23 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/73717a51063b

8143955: JShell tool (UX): Output structure
8143956: JShell tool (UX): default prompts
Reviewed-by: jlahoda

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! 
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties
! src/jdk.jshell/share/classes/jdk/jshell/Eval.java
! test/jdk/jshell/EditorPadTest.java
! test/jdk/jshell/EditorTestBase.java
! test/jdk/jshell/ExternalEditorTest.java
! test/jdk/jshell/ReplToolTesting.java
! test/jdk/jshell/T8146368/JShellToolTest8146368.java
! test/jdk/jshell/ToolBasicTest.java
! test/jdk/jshell/ToolReloadTest.java
! test/jdk/jshell/ToolSimpleTest.java

Changeset: 65837a9d9c4a
Author:jlahoda
Date:  2016-04-13 09:50 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/65837a9d9c4a

8150641: Repeated compilation with a long classpath significantly slower on JDK 
9
Summary: Caching resolved zip paths, and their non-existence; introducing an 
abstraction over jrtfs, directory and zipfs.
Reviewed-by: jjg

! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTool.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java

Changeset: a399f56c42aa
Author:jlahoda
Date:  2016-04-13 19:44 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a399f56c42aa

8154149: tools/javac/unit/T6198196.java broken on Windows after JDK-8150641
Summary: Avoiding interference among sub-tests due to CacheFSInfo by using a 
new file manager for each sub-test
Reviewed-by: jjg

! test/tools/javac/unit/T6198196.java

Changeset: 9326e37434ee
Author:lana
Date:  2016-04-14 09:34 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9326e37434ee

Merge


Changeset: eaa3ac6a778a
Author:ksrini
Date:  2016-04-14 14:30 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/eaa3ac6a778a

8152818: Javadoc must support module options supported by javac.
Reviewed-by: jjg, martin

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties

Changeset: 31c8b18fdc5b
Author:jjg
Date:  2016-04-14 17:51 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/31c8b18fdc5b

8149757: Implement Multi-Release JAR aware JavacFileManager for javac
Reviewed-by: jjg, jlahoda
Contributed-by: steve.dr...@oracle.com

! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTool.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
+ test/tools/javac/file/MultiReleaseJar/MultiReleaseJarAwareSJFM.java
+ test/tools/javac/file/MultiReleaseJar/MultiReleaseJarTest.java

Changeset: dd5907bca0a4
Author:lana
Date:  2016-04-21 12:57 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/dd5907bca0a4

Added tag jdk-9+115 for changeset 31c8b18fdc5b

! .hgtags

Changeset: 542e14c460d6
Author:alanb
Date:  2016-04-22 09:29 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/542e14c460d6

Merge

! .hgtags
! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties
! test/jdk/jshell/T8146368/JShellToolTest8146368.java

hg: jigsaw/jake/jaxp: 5 new changesets

[alan . bateman]

Changeset: 8be5606f3ea3
Author:joehw
Date:  2016-04-12 14:44 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/8be5606f3ea3

8151162: Public entries not searched when prefer='system'
Reviewed-by: lancea

! src/java.xml/share/classes/javax/xml/catalog/CatalogResolverImpl.java
! src/java.xml/share/classes/javax/xml/catalog/CatalogUriResolverImpl.java
! src/java.xml/share/classes/javax/xml/catalog/GroupEntry.java
! src/java.xml/share/classes/javax/xml/catalog/Util.java
! test/javax/xml/jaxp/unittest/catalog/CatalogTest.java
+ test/javax/xml/jaxp/unittest/catalog/pubOnly.xml
+ test/javax/xml/jaxp/unittest/catalog/sysAndPub.xml
+ test/javax/xml/jaxp/unittest/catalog/sysOnly.xml

Changeset: ffec86e316e7
Author:lana
Date:  2016-04-14 09:33 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/ffec86e316e7

Merge


Changeset: 1902a5bda18e
Author:joehw
Date:  2016-04-14 16:36 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/1902a5bda18e

8152527: Relative rewriteSystem with xml:base at group level failed
Reviewed-by: lancea

! src/java.xml/share/classes/javax/xml/catalog/GroupEntry.java
! test/javax/xml/jaxp/unittest/catalog/CatalogTest.java
+ test/javax/xml/jaxp/unittest/catalog/rewriteSystem_id.xml

Changeset: 5a17325d8118
Author:lana
Date:  2016-04-21 12:57 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/5a17325d8118

Added tag jdk-9+115 for changeset 1902a5bda18e

! .hgtags

Changeset: e3be851354a7
Author:alanb
Date:  2016-04-22 07:43 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/e3be851354a7

Merge

hg: jigsaw/jake: 26 new changesets

[alan . bateman]

Changeset: 2abe79f8c412
Author:erikj
Date:  2016-04-12 15:20 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/2abe79f8c412

8154070: Configuration script unable to detect boot JDK's modules support
Reviewed-by: alanb

! common/autoconf/boot-jdk.m4
! common/autoconf/generated-configure.sh

Changeset: b490dd2121ac
Author:kzhaldyb
Date:  2016-02-16 15:25 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/b490dd2121ac

8146287: typos in /test/failure_handler
Reviewed-by: iignatyev, stsmirno

! test/failure_handler/Makefile
! test/failure_handler/test/sanity/Suicide.java

Changeset: 922839953828
Author:kzhaldyb
Date:  2016-02-16 15:36 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/922839953828

8149780: GatherProcessInfoTimeoutHandler shouldn't call getWin32Pid if the lib 
isn't load
Reviewed-by: iignatyev, stsmirno

! 
test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherProcessInfoTimeoutHandler.java

Changeset: 63bacca32a57
Author:jwilhelm
Date:  2016-03-19 01:23 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/63bacca32a57

Merge


Changeset: 60842ab238ca
Author:jwilhelm
Date:  2016-03-23 20:12 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/60842ab238ca

Merge


Changeset: caf370438764
Author:dfazunen
Date:  2016-03-30 17:24 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/caf370438764

8152422: Optimize GC JPRT test set
Reviewed-by: sjohanss, pliden

! make/jprt.properties

Changeset: 15c37952af8f
Author:ctornqvi
Date:  2016-03-30 11:15 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/15c37952af8f

8153071: Remove client testing from JPRT
Reviewed-by: dcubed, gtriantafill

! make/jprt.properties

Changeset: 7e415988cbad
Author:ctornqvi
Date:  2016-03-30 20:01 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/7e415988cbad

Merge

! make/jprt.properties

Changeset: 10fc3d11f4c4
Author:ctornqvi
Date:  2016-03-31 11:42 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/10fc3d11f4c4

8150899: [TESTBUG] Split hotspot_all job into smaller jobs
Reviewed-by: gtriantafill, iignatyev

! make/jprt.properties

Changeset: b2c757cb9904
Author:jwilhelm
Date:  2016-04-02 05:30 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/b2c757cb9904

Merge


Changeset: 9e014eb1c0bf
Author:dcubed
Date:  2016-04-07 08:48 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/9e014eb1c0bf

Merge


Changeset: 0aef6b371e44
Author:jcm
Date:  2016-04-04 02:10 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/0aef6b371e44

8067247: Crash: assert(method_holder->data() == 0 ...) failed: a) MT-unsafe 
modification of inline cache
Summary: Made invoker LambdaForm instance & its compiled form lifetime tightly 
coupled.
Reviewed-by: vlivanov

! test/lib/sun/hotspot/WhiteBox.java

Changeset: a396eea6a178
Author:bharadwaj
Date:  2016-04-05 15:39 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/a396eea6a178

Merge


Changeset: 512906ad475a
Author:bharadwaj
Date:  2016-04-08 12:36 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/512906ad475a

Merge


Changeset: b72d1bf91ec1
Author:amurillo
Date:  2016-04-11 14:21 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/b72d1bf91ec1

Merge


Changeset: 680189242eea
Author:amurillo
Date:  2016-04-13 00:00 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/680189242eea

Merge


Changeset: b866d54ff8f5
Author:erikj
Date:  2016-04-13 18:11 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/b866d54ff8f5

8153969: Clean up module src dir logic
Reviewed-by: ihse

! make/CompileJavaModules.gmk
! make/GensrcModuleInfo.gmk
! make/common/MakeBase.gmk
! make/common/Modules.gmk
! test/make/TestMakeBase.gmk

Changeset: 55cf2b46a77a
Author:erikj
Date:  2016-04-14 15:13 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/55cf2b46a77a

8149777: Enable enhanced failure handler for "make test"
Reviewed-by: ihse

! make/Main.gmk
+ make/test/BuildFailureHandler.gmk
! test/failure_handler/README
- 
test/failure_handler/src/windows/native/jdk/test/failurehandler/jtreg/GatherProcessInfoTimeoutHandler.c
+ 
test/failure_handler/src/windows/native/libtimeoutHandler/GatherProcessInfoTimeoutHandler.c

Changeset: 300bad1862c5
Author:erikj
Date:  2016-04-14 16:42 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/300bad1862c5

8154237: Compare script broken for windows native library deps comparison
Reviewed-by: tbell

! common/bin/compare.sh

Changeset: 6fefc7b2aade
Author:lana
Date:  2016-04-14 09:32 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/6fefc7b2aade

Merge

- 
test/failure_handler/src/windows/native/jdk/test/failurehandler/jtreg/GatherProcessInfoTimeoutHandler.c

Changeset: ec69c5bf68a6
Author:neugens
Date:  2016-04-15 14:57 +0200
URL:   

hg: jigsaw/jake/jaxws: 2 new changesets

[alan . bateman]

Changeset: 529f0bf896e5
Author:lana
Date:  2016-04-21 12:57 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/529f0bf896e5

Added tag jdk-9+115 for changeset 4ff86e5489e4

! .hgtags

Changeset: 892b6c3e7ea7
Author:alanb
Date:  2016-04-22 07:43 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/892b6c3e7ea7

Merge

hg: jigsaw/jake/nashorn: 3 new changesets

[alan . bateman]

Changeset: 295ac208a444
Author:chegar
Date:  2016-04-15 16:19 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/295ac208a444

8137058: Clear out all non-Critical APIs from sun.reflect
Reviewed-by: alanb, jfranck, mchung

! src/jdk.dynalink/share/classes/jdk/dynalink/beans/AbstractJavaLinker.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java

Changeset: 208388a5622d
Author:lana
Date:  2016-04-21 12:57 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/208388a5622d

Added tag jdk-9+115 for changeset 295ac208a444

! .hgtags

Changeset: 98ff6dc92733
Author:alanb
Date:  2016-04-22 07:43 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/98ff6dc92733

Merge

! .hgtags
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java

hg: jigsaw/jake/corba: 3 new changesets

[alan . bateman]

Changeset: 7bab1b1b3682
Author:chegar
Date:  2016-04-15 16:19 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/7bab1b1b3682

8137058: Clear out all non-Critical APIs from sun.reflect
Reviewed-by: alanb, jfranck, mchung

! src/java.corba/share/classes/sun/corba/Bridge.java

Changeset: 20198ae6eb3e
Author:lana
Date:  2016-04-21 12:57 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/20198ae6eb3e

Added tag jdk-9+115 for changeset 7bab1b1b3682

! .hgtags

Changeset: 08b6b0e7590a
Author:alanb
Date:  2016-04-22 07:43 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/08b6b0e7590a

Merge

hg: jigsaw/jake/hotspot: 265 new changesets

[alan . bateman]

Changeset: 70375b3285d9
Author:mgerdin
Date:  2016-03-07 17:23 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/70375b3285d9

8151178: Move the collection set out of the G1 collector policy
Summary: Create a G1CollectionSet class
Reviewed-by: jwilhelm, tbenson, tschatzl

! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1CollectedHeap.hpp
+ src/share/vm/gc/g1/g1CollectionSet.cpp
+ src/share/vm/gc/g1/g1CollectionSet.hpp
! src/share/vm/gc/g1/g1CollectorPolicy.cpp
! src/share/vm/gc/g1/g1CollectorPolicy.hpp
! src/share/vm/gc/g1/g1CollectorState.hpp
! src/share/vm/gc/g1/g1ParScanThreadState.cpp
! src/share/vm/gc/g1/g1YoungRemSetSamplingThread.cpp
! src/share/vm/gc/g1/youngList.cpp

Changeset: 8afc97475eba
Author:csahu
Date:  2016-03-08 14:37 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8afc97475eba

8146683: check_addr0 should be more efficient
Reviewed-by: dsamersoff, kevinw, dholmes
Contributed-by: cheleswer.s...@oracle.com

! src/os/solaris/vm/os_solaris.cpp

Changeset: c5926c871707
Author:ehelin
Date:  2016-03-07 10:36 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c5926c871707

8151365: Move G1YoungGenSizer to a separate file
Reviewed-by: mgerdin, tschatzl

! src/share/vm/gc/g1/g1CollectorPolicy.cpp
+ src/share/vm/gc/g1/g1YoungGenSizer.cpp
+ src/share/vm/gc/g1/g1YoungGenSizer.hpp

Changeset: 2dbbb7996514
Author:ehelin
Date:  2016-03-08 14:54 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2dbbb7996514

Merge


Changeset: 899be832e91d
Author:rprotacio
Date:  2016-03-08 12:57 -0500
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/899be832e91d

8149991: Convert TraceSafepointCleanupTime to Unified Logging
Summary: Converted TraceSafepointCleanupTime to -Xlog:safepointcleanup=info
Reviewed-by: hseigel, mockner, ddmitriev, dholmes, coleenp

! src/share/vm/logging/logTag.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/logTimer.hpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/timer.cpp
+ test/runtime/logging/SafepointCleanupTest.java

Changeset: 59d3a69564dc
Author:rprotacio
Date:  2016-03-08 15:19 -0500
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/59d3a69564dc

8150083: Convert VerboseVerification to Unified Logging
Summary: Converted -XX:+VerboseVerfication to -Xlog:verboseverification=info
Reviewed-by: hseigel, dholmes

! src/share/vm/classfile/verifier.cpp
! src/share/vm/logging/logTag.hpp
! src/share/vm/runtime/globals.hpp
! test/runtime/logging/ClassInitializationTest.java
+ test/runtime/logging/VerboseVerificationTest.java

Changeset: 2d1f1d4c0379
Author:tonyp
Date:  2016-03-09 09:45 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2d1f1d4c0379

8146991: Introduce per-worker preserved mark stacks in ParallelGC
Reviewed-by: tschatzl, ysr

! src/share/vm/gc/parallel/psPromotionManager.cpp
! src/share/vm/gc/parallel/psPromotionManager.hpp
! src/share/vm/gc/parallel/psScavenge.cpp
! src/share/vm/gc/parallel/psScavenge.hpp
! src/share/vm/gc/shared/preservedMarks.cpp
! src/share/vm/gc/shared/preservedMarks.hpp

Changeset: 47a9289d9b0b
Author:tschatzl
Date:  2016-03-09 09:56 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/47a9289d9b0b

8151414: os::pretouch_memory should take void* instead of char*
Summary: Change parameters and remove associated casts.
Reviewed-by: pliden, stefank

! src/share/vm/gc/parallel/mutableSpace.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp

Changeset: 51330f8324b6
Author:sla
Date:  2016-03-09 12:30 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/51330f8324b6

8151196: Several tests fail due to test library not found
Reviewed-by: ctornqvi, brutisso

! test/gc/g1/plab/TestPLABPromotion.java
! test/gc/g1/plab/TestPLABResize.java
! test/serviceability/dcmd/gc/HeapDumpAllTest.java
! test/serviceability/dcmd/gc/HeapDumpTest.java

Changeset: 189efe045210
Author:brutisso
Date:  2016-03-09 14:05 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/189efe045210

8151513: Remove debugging code from BarrierSet
Reviewed-by: pliden, stefank

! src/share/vm/gc/shared/barrierSet.cpp
! src/share/vm/gc/shared/barrierSet.inline.hpp

Changeset: f81ea6b38171
Author:brutisso
Date:  2016-03-09 14:54 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f81ea6b38171

Merge


Changeset: 5322bfdc760a
Author:jwilhelm
Date:  2016-03-09 14:18 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5322bfdc760a

Merge

! src/share/vm/code/codeCache.cpp
! src/share/vm/code/codeCache.hpp
! src/share/vm/code/nmethod.cpp
- src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.cpp
- src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.hpp
! src/share/vm/runtime/arguments.cpp
! test/TEST.groups

Changeset: 572d669d17cd
Author: 

hg: jigsaw/jake/jdk: 75 new changesets

[alan . bateman]

Changeset: 463463e306e0
Author:smarks
Date:  2016-04-11 11:45 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/463463e306e0

8145461: finalize and integrate @Deprecated annotation specification change
Reviewed-by: scolebourne, chegar, lancea

! src/java.base/share/classes/java/lang/Deprecated.java

Changeset: a74c31f08a47
Author:peytoia
Date:  2016-04-12 10:15 +0900
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a74c31f08a47

8150324: java/util/Currency/CurrencyTest.java does not restore default TimeZone
Reviewed-by: okutsu, peytoia
Contributed-by: Nishit Jain 

! test/java/util/Currency/CurrencyTest.java

Changeset: a1b34a5ff412
Author:amlu
Date:  2016-04-12 09:54 +0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a1b34a5ff412

8154031: Mark tools/pack200/BandIntegrity.java as intermittently failing
Reviewed-by: darcy

! test/tools/pack200/BandIntegrity.java

Changeset: e6196d754c4e
Author:amlu
Date:  2016-04-12 13:53 +0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e6196d754c4e

8068693: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing.
8153209: java/nio/channels/AsyncCloseAndInterrupt.java fails throwing 
exception: java.nio.channels.ClosedChannelException.
Summary: for JDK-8068693, 500ms is too short on busy system for channel to be 
closed or for thread blocking on IO to be interrupted, increase the time from 
500ms to 1ms. for JDK-8153209, it's a test regression due to JDK-8151582, 
do not sleep when running tests for CONNECT/FINISH_CONNECT, sleep for other 
test cases.
Reviewed-by: bpb, martin, rriggs
Contributed-by: Hamlin Li 

! test/java/nio/channels/AsyncCloseAndInterrupt.java

Changeset: 1ac040116965
Author:redestad
Date:  2016-04-12 18:25 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1ac040116965

8153213: Jar manifest attribute "Multi-Release" accepts any value
Reviewed-by: psandoz, redestad
Contributed-by: steve.dr...@oracle.com

! src/java.base/share/classes/java/util/jar/JarFile.java
! test/java/util/jar/JarFile/MultiReleaseJarAPI.java
! test/lib/testlibrary/java/util/jar/CreateMultiReleaseTestJars.java

Changeset: 1f8c4b1a301c
Author:rhalade
Date:  2016-04-12 09:37 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1f8c4b1a301c

8153829: javax/net/ssl/Stapling/HttpsUrlConnClient.java fails intermittently 
with NullPointerException
Reviewed-by: xuelei, jnimeh

! test/java/security/testlibrary/SimpleOCSPServer.java
! test/javax/net/ssl/Stapling/HttpsUrlConnClient.java
! test/javax/net/ssl/Stapling/SSLEngineWithStapling.java
! test/javax/net/ssl/Stapling/SSLSocketWithStapling.java
! test/javax/net/ssl/Stapling/StapleEnableProps.java
! 
test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java

Changeset: ff4e699b02cc
Author:redestad
Date:  2016-04-12 21:41 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ff4e699b02cc

8154067: Avoid early use of limited privilege escalation in 
InnerClassLambdaMetafactory
Reviewed-by: alanb, mchung, mullan, briangoetz

! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java

Changeset: cde5f640f82b
Author:mchung
Date:  2016-04-12 18:58 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cde5f640f82b

8153665: URLClassLoader::definePackage no longer inspect packages from ancestors
Reviewed-by: alanb

! src/java.base/share/classes/java/net/URLClassLoader.java
+ test/java/net/URLClassLoader/definePackage/SplitPackage.java
+ test/java/net/URLClassLoader/definePackage/p/Bar.java
+ test/java/net/URLClassLoader/definePackage/p/Baz.java
+ test/java/net/URLClassLoader/definePackage/p/Foo.java

Changeset: fdc920e40e35
Author:jwilhelm
Date:  2016-03-09 14:18 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fdc920e40e35

Merge


Changeset: 92aaccaffea7
Author:coleenp
Date:  2016-03-10 14:20 -0500
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/92aaccaffea7

8150778: Reduce Throwable.getStackTrace() calls to the JVM
Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, with 
JVM_GetStackTraceElements that gets all the elements in the StackTraceElement[]
Reviewed-by: dfuchs, mchung, shade, hseigel

! make/mapfiles/libjava/mapfile-vers
! make/mapfiles/libjava/reorder-sparc
! make/mapfiles/libjava/reorder-sparcv9
! make/mapfiles/libjava/reorder-x86
! src/java.base/share/classes/java/lang/StackTraceElement.java
! src/java.base/share/classes/java/lang/Throwable.java
! src/java.base/share/native/include/jvm.h
! src/java.base/share/native/libjava/Throwable.c

Changeset: cba76eb01f49
Author:ysuenaga
Date:  2016-03-04 18:13 +0900
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cba76eb01f49

8151181: Add JSnap to jhsdb
Reviewed-by: dsamersoff

! test/sun/tools/jhsdb/BasicLauncherTest.java

Changeset: a67d225b677f
Author:ysuenaga
Date:  2016-03-15 

Re: requires public for automatic modules

[Paul Bakker]

Thanks for the answer Remi. I'm wondering if a (optional) build step is 
considered. During build the byte code analysis that jdeps does could be used 
to generate better metadata for automatic modules. This would be a compromise 
between using automatic modules without this metadata and actually adding a 
module-info to a JAR file (which isn't a great option for 3rd party libs).

I've looked at several (small) code bases now, and using default modules keep 
resulting in a long list of transitive dependencies that I would prefer not to 
have in my module. Because of that a top down migration process doesn't result 
in proper modules when using automatic modules, and that would be a bad start 
when migrating to modules. The required trial and error work will frustrate 
users as well.

Paul



> On 22 Apr 2016, at 11:12, Remi Forax  wrote:
> 
> Hi Paul,
> 
> - Mail original -
>> De: "Paul Bakker" 
>> À: jigsaw-dev@openjdk.java.net
>> Envoyé: Vendredi 22 Avril 2016 10:52:23
>> Objet: requires public for automatic modules
>> 
>> Hello,
>> 
>> I'm experimenting with automatic modules again. I have a module
>> "demonstrator" that uses Jackson Databind.
>> 
>>  import com.fasterxml.jackson.databind.ObjectMapper;
>>  
>>  ObjectMapper mapper = new ObjectMapper();
>>  String json = mapper.writeValueAsString(modularityBook);
>> 
>> In module-info.java I have the following:
>> 
>>  requires jackson.databind;
>> 
>> On the modulepath I have jackson.core, jackson.databind and
>> jackson.annotations.
>> Building results in an error:
>>  
>>   class file for com.fasterxml.jackson.core.Versioned not found
>> 
>> This makes sense because the ObjectMapper class that I'm using implements the
>> Versioned interface (from jackson.core).
>> When generating a module-info.java using jdeps for the jackson.databind JAR
>> however, it generates the following:
>> 
>>  requires public jackson.annotations;
>>  requires public jackson.core;
>> 
>> This is much closer to what I would expect when using the jackson.databind
>> module.
>> When using jackson.databind as an automatic module, I will end up with a list
>> of requires for transitive dependencies that I shouldn't have to care about.
>> Why don't automatic modules take better care of transitive dependencies, so
>> that the application's module-info looks similar to what it would after
>> transforming the dependencies to named modules?
>> 
> 
> because it will require the runtime to parse the bytecode of an automatic 
> module, which is a slow operation.
> 
>> Also, jdeps doesn't actually show this problem when looking at the code when
>> still on the classpath:
>> 
>>  jdeps -cp lib/jackson-databind-2.7.3.jar
>>  out/com/javamodularity/demonstrator/Demo.class
>>  
>>  Demo.class -> lib/jackson-databind-2.7.3.jar
>>  Demo.class -> java.base
>> com.javamodularity.demonstrator (Demo.class)
>>-> com.fasterxml.jackson.databind
>>jackson-databind-2.7.3.jar
>>-> java.io
>>-> java.lang
>> 
>> Best regards,
>> 
>> Paul Bakker
>> 
>> 
>> 
> 
> regards,
> 
> Rémi

Re: requires public for automatic modules

[Alan Bateman]

On 22/04/2016 09:52, Paul Bakker wrote:

Why don't automatic modules take better care of transitive dependencies, so 
that the application's module-info looks similar to what it would after 
transforming the dependencies to named modules?


As Rémi said, there isn't any static analysis done at compile time or 
run time to figure out the dependences. It would be costly to do this 
and of course no guarantee that it would be accurate/complete.


For that reason, automatic modules are specified to only require 
java.base and you can confirm this if you use -listmods to list/describe 
these modules:


java -mp lib -listmods:jackson.core,jackson.databind,jackson.annotations

So in your scenario then "demonstrator" requires jackson.databind but 
there is nobody that transitively depends on jackson.core or 
jackson.annotations and so neither module is resolved. You can of course 
use -addmods if you need it.


I guess it's worth repeating that automatic modules are for migration 
and bridging to the class path. In the scenario then you'd like to 
create a module "demonstrator" that depends on Jackson databind but that 
project hasn't embraced modules yet. You move jackson-databind-2.6.jar 
to the module path where it becomes a module with a name 
("jackson.databind" in this case) and that allows you to make progress 
on compiling and deploying "demonstrator" as a module. At this point 
then you can leave the other JAR files on the class path and the code in 
jackson.databind will link to whatever types it needs from the other 
Jackson components.


-Alan.

Re: requires public for automatic modules

[Paul Bakker]

Hi Alan,

Thanks, the -addmods hint is a very useful one, I had not tried that yet. After 
adding the jackson.core and jackson.annotations explicitly to -addmods, I can 
compile/run without depending on them in my demonstrator module. That's a good 
workaround.

Paul




> On 22 Apr 2016, at 13:16, Alan Bateman  wrote:
> 
> On 22/04/2016 09:52, Paul Bakker wrote:
>> Why don't automatic modules take better care of transitive dependencies, so 
>> that the application's module-info looks similar to what it would after 
>> transforming the dependencies to named modules?
>> 
>> 
> As Rémi said, there isn't any static analysis done at compile time or run 
> time to figure out the dependences. It would be costly to do this and of 
> course no guarantee that it would be accurate/complete.
> 
> For that reason, automatic modules are specified to only require java.base 
> and you can confirm this if you use -listmods to list/describe these modules:
> 
> java -mp lib -listmods:jackson.core,jackson.databind,jackson.annotations
> 
> So in your scenario then "demonstrator" requires jackson.databind but there 
> is nobody that transitively depends on jackson.core or jackson.annotations 
> and so neither module is resolved. You can of course use -addmods if you need 
> it.
> 
> I guess it's worth repeating that automatic modules are for migration and 
> bridging to the class path. In the scenario then you'd like to create a 
> module "demonstrator" that depends on Jackson databind but that project 
> hasn't embraced modules yet. You move jackson-databind-2.6.jar to the module 
> path where it becomes a module with a name ("jackson.databind" in this case) 
> and that allows you to make progress on compiling and deploying 
> "demonstrator" as a module. At this point then you can leave the other JAR 
> files on the class path and the code in jackson.databind will link to 
> whatever types it needs from the other Jackson components.
> 
> -Alan.
> 

Re: requires public for automatic modules

[Alan Bateman]

On 22/04/2016 11:36, Paul Bakker wrote:

Thanks for the answer Remi. I'm wondering if a (optional) build step is 
considered. During build the byte code analysis that jdeps does could be used 
to generate better metadata for automatic modules. This would be a compromise 
between using automatic modules without this metadata and actually adding a 
module-info to a JAR file (which isn't a great option for 3rd party libs).

I've looked at several (small) code bases now, and using default modules keep 
resulting in a long list of transitive dependencies that I would prefer not to 
have in my module. Because of that a top down migration process doesn't result 
in proper modules when using automatic modules, and that would be a bad start 
when migrating to modules. The required trial and error work will frustrate 
users as well.
The intention when doing top-down isn't to do a bulk move, otherwise you 
end up with many automatic modules on the module path that nobody 
requires and then resorting to `-addmods ALL-MODULE-PATH`.


Instead, the intention is that you just move the components that 
"demonstrator" requires. This might mean using `jdeps` when migrating 
existing code, maybe using the -genmoduleinfo` option to generate an 
initial module-info.java to get you going.  The rest can be left on the 
class path until the owners of components that have moved are released 
as explicit modules.


That said, automatic modules and top-level migration is very much an 
area that needs real world experience and feedback. We definitely need 
more people trying it out and reporting back on whether they were 
successful or not.


-Alan

RFR: JDK-8082537 - jimage should print usage when started with no args

[Jim Laskey (Oracle)]

Now prints usage.

http://cr.openjdk.java.net/~jlaskey/8082537/webrev/index.html 

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

RFR: JDK-8153930 - Compiler crashed (intermittently)

[Jim Laskey (Oracle)]

Two race conditions eliminated and ImageReader made idempotent.

http://cr.openjdk.java.net/~jlaskey/8153930/webrev/index.html 
 (Note webrev 
fails to diff ImageReader.java, best to view new file.)
https://bugs.openjdk.java.net/browse/JDK-8153930 

RFR: JDK-8154090 - Remove support for jimage recreate

[Jim Laskey (Oracle)]

http://cr.openjdk.java.net/~jlaskey/8154090/webrev/index.html 

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

RFR: JDK-8147426 - Missing definition for JIMAGE_NOT_FOUND

[Jim Laskey (Oracle)]

JIMAGE_NOT_FOUND was defined in the hotspot jimage.hpp header but not in the 
jdk jimage.hpp header.  Brought the headers in line.

http://cr.openjdk.java.net/~jlaskey/8147426/webrev/index.html 

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

RFR: JDK-8154179 - BasicImageReader activating ImageBufferCache when not used

[Jim Laskey (Oracle)]

The unused cache is being unnecessarily activated (ThreadLocal) when buffers 
are being released. 

http://cr.openjdk.java.net/~jlaskey/8154179/webrev/index.html 

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

RFR: JDK-8069079 - jimage extract / list to organize classes by modules

[Jim Laskey (Oracle)]

Listing is by module, extract has been by module for some time.

http://cr.openjdk.java.net/~jlaskey/8069079/webrev/index.html 

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

RFR: JDK-8147634 - Need a JImage API that given a JImageLocationRef returns class name

[Jim Laskey (Oracle)]

Implemented as requested by the runtime team.

http://cr.openjdk.java.net/~jlaskey/8147634/webrev/index.html 

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

Re: RFR: JDK-8153930 - Compiler crashed (intermittently)

[Claes Redestad]

Hi Jim,

the openers field could (maybe even should) be final, otherwise this 
looks really good!


Thanks!

/Claes

On 2016-04-22 15:12, Jim Laskey (Oracle) wrote:

Two race conditions eliminated and ImageReader made idempotent.

http://cr.openjdk.java.net/~jlaskey/8153930/webrev/index.html 
 (Note webrev 
fails to diff ImageReader.java, best to view new file.)
https://bugs.openjdk.java.net/browse/JDK-8153930 

Re: RFR: JDK-8154179 - BasicImageReader activating ImageBufferCache when not used

[Claes Redestad]

+1

On 2016-04-22 15:12, Jim Laskey (Oracle) wrote:

The unused cache is being unnecessarily activated (ThreadLocal) when buffers 
are being released.

http://cr.openjdk.java.net/~jlaskey/8154179/webrev/index.html 

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

Re: java.lang.reflect.Module.WeakSet is not thread-safe

[Peter Levart]

Hi Alan,

Thanks for taking a look.

On 04/21/2016 10:41 PM, Alan Bateman wrote:


On 21/04/2016 20:52, Rémi Forax wrote:
I remember seeing this codd an thinking that synchronized should do 
the job.

I don't believe this use case requires something more complex.

Remi
I've taken a first pass over it and WeakPairMap seems straight-forward 
to use but its implementation, with Pair/Weak/Primary/Secondary/Lookup 
is complex.


Prior to #ReflectionWithoutReadability then transientReads was 
important, less so now although I think we should continue to allow 
concurrent lookups.


-Alan



I tried to reduce the complexity of WeakPairMap as much as I could. I 
added some docs that describe the architecture. Hopefully this is now 
easier to grasp:


http://cr.openjdk.java.net/~plevart/jdk9-dev/Module.WeakSet.multithreadUnsafe/webrev.03/

Another possibility for transientReads and transientExports (but not for 
transientUses) could be if each instance of Module object held a unique 
long id allocated at its creation from say AtomicLong. You could then 
construct maps with Long ids instead of Module(s), but that has a 
drawback that some Module (say a system module or a module of an app 
server) could accumulate ids from modules long gone (for example when 
some app in an app server is redeployed multiple times) so this would be 
a memory leak...


a single global WeakPairMap has an advantage over individual WeakSet(s) 
per Module instance because it is accessed more frequently so expunging 
of stale entries happens more promptly.


Regards, Peter

Re: RFR: JDK-8082537 - jimage should print usage when started with no args

[Alan Bateman]

On 22/04/2016 14:12, Jim Laskey (Oracle) wrote:

Now prints usage.

http://cr.openjdk.java.net/~jlaskey/8082537/webrev/index.html 

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


Does this need to be in the try/catch? I can't quickly tell if the 
getMessage can potentially throw BadArgs.


-Alan

Re: RFR: JDK-8154090 - Remove support for jimage recreate

[Alan Bateman]

On 22/04/2016 14:12, Jim Laskey (Oracle) wrote:

http://cr.openjdk.java.net/~jlaskey/8154090/webrev/index.html 

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



This looks to me assuming that it's only the one test that needs changing.

-Alan

Re: RFR: JDK-8082537 - jimage should print usage when started with no args

[Jim Laskey (Oracle)]

It can be outside, does the change add value?

> On Apr 22, 2016, at 10:12 AM, Jim Laskey (Oracle)  
> wrote:
> 
> Now prints usage.
> 
> http://cr.openjdk.java.net/~jlaskey/8082537/webrev/index.html 
> 
> https://bugs.openjdk.java.net/browse/JDK-8082537 
> 
> 

Re: RFR: JDK-8069079 - jimage extract / list to organize classes by modules

[Alan Bateman]

On 22/04/2016 14:12, Jim Laskey (Oracle) wrote:

Listing is by module, extract has been by module for some time.

http://cr.openjdk.java.net/~jlaskey/8069079/webrev/index.html 

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


This looks okay to me. I suspect Mandy will want to look at this too as 
she brought up this issue (I think prior to extract changing).


-Alan.

Re: RFR: JDK-8082537 - jimage should print usage when started with no args

[Alan Bateman]

On 22/04/2016 14:54, Jim Laskey (Oracle) wrote:

It can be outside, does the change add value?


I think so as it's always been odd that the jimage tool would exit 
without printing anything when calling without any arguments. My comment 
on the place of the check is that it wasn't clear why it is done in the 
try/catch, it's a minor comment/question, nothing more.


-Alan

Re: RFR: JDK-8082537 - jimage should print usage when started with no args

[Jim Laskey (Oracle)]

Will change.  Thank you.

> On Apr 22, 2016, at 10:59 AM, Alan Bateman  wrote:
> 
> 
> 
> On 22/04/2016 14:54, Jim Laskey (Oracle) wrote:
>> It can be outside, does the change add value?
>> 
>> 
> I think so as it's always been odd that the jimage tool would exit without 
> printing anything when calling without any arguments. My comment on the place 
> of the check is that it wasn't clear why it is done in the try/catch, it's a 
> minor comment/question, nothing more.
> 
> -Alan

Re: RFR: JDK-8069079 - jimage extract / list to organize classes by modules

[Jim Laskey (Oracle)]

Thank you, will wait.

> On Apr 22, 2016, at 10:55 AM, Alan Bateman  wrote:
> 
> 
> 
> On 22/04/2016 14:12, Jim Laskey (Oracle) wrote:
>> Listing is by module, extract has been by module for some time.
>> 
>> http://cr.openjdk.java.net/~jlaskey/8069079/webrev/index.html 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8069079 
>> 
>> 
> This looks okay to me. I suspect Mandy will want to look at this too as she 
> brought up this issue (I think prior to extract changing).
> 
> -Alan.

Re: RFR: JDK-8154090 - Remove support for jimage recreate

[Jim Laskey (Oracle)]

Thank you.

> On Apr 22, 2016, at 10:53 AM, Alan Bateman  wrote:
> 
> 
> 
> On 22/04/2016 14:12, Jim Laskey (Oracle) wrote:
>> http://cr.openjdk.java.net/~jlaskey/8154090/webrev/index.html 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8154090 
>> 
>> 
> This looks to me assuming that it's only the one test that needs changing.
> 
> -Alan

Build craziness

[Jim Laskey (Oracle)]

make clean ; make images

Building target 'images' in configuration 
'macosx-x86_64-normal-server-fastdebug'
Building JVM variant 'server' with features 'all-gcs cds compiler1 compiler2 
dtrace fprof jni-check jvmci jvmti management nmt services vm-structs'
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Creating adlc from 13 file(s)
Creating libjsig.dylib from 1 file(s)
dtrace: failed to compile script 
/Projects/jdk9-dev/build/macosx-x86_64-normal-server-fastdebug/hotspot/variant-server/support/dtrace/hotspot.h.d:
 line 1: empty D program translation unit
make[4]: *** 
[/Projects/jdk9-dev/build/macosx-x86_64-normal-server-fastdebug/hotspot/variant-server/gensrc/dtracefiles/hotspot.h]
 Error 1
make[4]: *** Waiting for unfinished jobs
make[3]: *** [variant-server-gensrc] Error 2
make[3]: *** Waiting for unfinished jobs
Compiling 19 properties into resource bundles for jdk.javadoc
Parsing 1 properties into enum-like class for jdk.compiler
Compiling 9 properties into resource bundles for jdk.jdeps
make[2]: *** [hotspot] Error 2
make[2]: *** Waiting for unfinished jobs
Compiling 3 properties into resource bundles for jdk.jshell
Compiling 16 properties into resource bundles for jdk.compiler

ERROR: Build failed for target 'images' in configuration 
'macosx-x86_64-normal-server-fastdebug' (exit code 2) 
=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_gensrc_dtracefiles_hotspot.h:
dtrace: failed to compile script 
/Projects/jdk9-dev/build/macosx-x86_64-normal-server-fastdebug/hotspot/variant-server/support/dtrace/hotspot.h.d:
 line 1: empty D program translation unit
=== End of repeated output ===
No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: If caused by a warning, try configure --disable-warnings-as-errors.

make[1]: *** [main] Error 2
make: *** [images] Error 2

Re: Build craziness

[Alan Bateman]

I don't recognize this it looks to be the DTrace support. I also see it 
is jdk9/dev. You might be better bringing it to build-dev with more 
details on the tool chain used.


-Alan

On 22/04/2016 15:59, Jim Laskey (Oracle) wrote:

make clean ; make images

Building target 'images' in configuration 
'macosx-x86_64-normal-server-fastdebug'
Building JVM variant 'server' with features 'all-gcs cds compiler1 compiler2 
dtrace fprof jni-check jvmci jvmti management nmt services vm-structs'
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Creating adlc from 13 file(s)
Creating libjsig.dylib from 1 file(s)
dtrace: failed to compile script 
/Projects/jdk9-dev/build/macosx-x86_64-normal-server-fastdebug/hotspot/variant-server/support/dtrace/hotspot.h.d:
 line 1: empty D program translation unit
make[4]: *** 
[/Projects/jdk9-dev/build/macosx-x86_64-normal-server-fastdebug/hotspot/variant-server/gensrc/dtracefiles/hotspot.h]
 Error 1
make[4]: *** Waiting for unfinished jobs
make[3]: *** [variant-server-gensrc] Error 2
make[3]: *** Waiting for unfinished jobs
Compiling 19 properties into resource bundles for jdk.javadoc
Parsing 1 properties into enum-like class for jdk.compiler
Compiling 9 properties into resource bundles for jdk.jdeps
make[2]: *** [hotspot] Error 2
make[2]: *** Waiting for unfinished jobs
Compiling 3 properties into resource bundles for jdk.jshell
Compiling 16 properties into resource bundles for jdk.compiler

ERROR: Build failed for target 'images' in configuration 
'macosx-x86_64-normal-server-fastdebug' (exit code 2)
=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_gensrc_dtracefiles_hotspot.h:
dtrace: failed to compile script 
/Projects/jdk9-dev/build/macosx-x86_64-normal-server-fastdebug/hotspot/variant-server/support/dtrace/hotspot.h.d:
 line 1: empty D program translation unit
=== End of repeated output ===
No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: If caused by a warning, try configure --disable-warnings-as-errors.

make[1]: *** [main] Error 2
make: *** [images] Error 2

Re: RFR: JDK-8069079 - jimage extract / list to organize classes by modules

[Mandy Chung]

Hi Jim,

> On Apr 22, 2016, at 6:12 AM, Jim Laskey (Oracle)  
> wrote:
> 
> Listing is by module, extract has been by module for some time.
> 
> http://cr.openjdk.java.net/~jlaskey/8069079/webrev/index.html 
> 


JDK-8069079 was filed long time ago and I now retested it. jimage list and 
extract in jdk9 works as what I'd like to see when filing the issue.

$ ./bin/jimage list lib/modules

jimage: modules
/java.activation/META-INF/mailcap.default
/java.activation/META-INF/mimetypes.default
/java.activation/com/sun/activation/registries/LineTokenizer.class
/java.activation/com/sun/activation/registries/LogSupport.class
:

The current output looks fine to me.  This issue can be issued.

A minor comment (a separate issue):

jimage: modules

It would help to print the path supplied in the command line than just the base 
filename.

$ ./bin/jimage list

This silently returns.  Since the list/extract command requires to specify the 
path to the jimage file, it would be helpful to report that.

Mandy

The javax.annotation.Generated and annotation processors

[Sanne Grinovero]

Hello all,

related to https://bugs.openjdk.java.net/browse/JDK-8152842

I'm having to patch our annotation processors to avoid the @Generated
annotation, as I can't use the proposed workaround to use `-addmods
java.annotations.common`: our build also requires `-target 1.7` and
the two options are not compatible.

But I hope this will be only very short term? I'm only working this
around temporarily so that I can keep testing other more interesting
aspects of Jigsaw, but ultimately we'll need that annotation back.

Thanks,
Sanne

Re: Root modules (was Re: JMH and JDK9)

[Sanne Grinovero]

On Wed, Apr 20, 2016 at 1:57 PM, Alan Bateman  wrote:
>
> (dropping hotspot-dev and change the subject line as this discussion thread
> has moved on)
>
> On 20/04/2016 13:28, Sanne Grinovero wrote:
>>
>> :
>> Agreed: excellent idea!
>>
>> I'm eager to try it out so that we can resume testing of everything
>> else too; I just tried my luck with build 9-ea+114 but it didn't seem
>> to work: I'm going to assume this wasn't implemented yet, or should I
>> double check how I'm building?
>> Did I understand correctly that I won't need to pass any switch to
>> neither java nor javac, as long as I have the JavaEE jar as external
>> dependencies on my classpath? (i.e. if this build is "proven" on Java8
>> it should work on Java9 ?)
>>
>> Is there an issue tracker which I could follow to watch updates on this?
>>
>> Slightly unrelated, but is it expected that compilation is successful,
>> even though (in my specific case) javax.transaction.Synchronization
>> causes a java.lang.NoClassDefFoundError at runtime?
>>
> It's in Jigsaw EA builds [1], it hasn't been brought into the JDK 9 main
> line yet.
>
> I'm not well aquatinted with of contents of the "Java EE jar" but I believe
> it has the API classes for the Java Transaction API, Common Annotations,
> JAXB, and JAX-WS. So if you are compiling or running with the Jigsaw EA
> builds then you should see that it won't locate these classes in the runtime
> image, instead they will be located on the class path in this JAR file.
>
> One thing to mention is that the JavaBeans Activiation Framework (package
> javax.activation). That was in EE 5 but doesn't appear in the javadoc for EE
> 6 or 7. I don't know the full story there but it remains a standalone
> technology and upgradable. If it's not in the Java EE JAR then and you don't
> have it on your class path then you will need `-addmods java.activation` to
> ensure that this module is resolved.
>
> On javax.transaction.Synchronization then I would not expect this to compile
> with jdk-9+114 because this type is not in the java.transaction. I would
> expect it will compile (and run) with the Jigsaw EA builds.

Thanks! Indeed, it's working great.

[tested 9-ea+114-2016-04-19-162931.javare.4880.nc]

Ironically this means we can make more progress testing using the
Jigsaw EA builds, while I'm completely blocked on the "mainline".

Thanks,
Sanne

>
> -Alan
>
> [1] https://jdk9.java.net/jigsaw/

Re: JMH and JDK9

[Sanne Grinovero]

On Wed, Apr 20, 2016 at 3:15 PM, Stephen Felts  wrote:
> There was a bug that was just fixed yesterday such that the Java EE classes 
> were not hidden.
> It should have been fixed in the last nightly 114 build.
>
> As long as the necessary Java EE API classes are on the classpath, no command 
> line options are needed.
>
> If you have the Java EE JTA API jar in the classpath, then use of 
> javax.transaction.Synchronization (which is not in the JDK but is in the JTA 
> API jar) will be resolved for both javac and java.

Thanks Stephen, indeed testing
9-ea+114-2016-04-19-162931.javare.4880.nc this is working great.

[Sorry all for the forked email thread.. I should have changed the
subject early on]

Regards,
Sanne


>
> -Original Message-
> From: Sanne Grinovero [mailto:sa...@redhat.com]
> Sent: Wednesday, April 20, 2016 8:29 AM
> To: Alan Bateman
> Cc: jigsaw-dev; hotspot-dev Source Developers
> Subject: Re: JMH and JDK9
>
> On Tue, Apr 5, 2016 at 3:16 PM, Andrew Dinn  wrote:
>> On 05/04/16 11:17, Alan Bateman wrote:
>>   . . .
>>> We recently updated JEP 261 proposing that "java.se" be the only
>>> java.* root module that is resolved when compiling code in the
>>> unnamed module or at runtime when the main class is loaded from the
>>> class path [1]. On the surface then it will "appear" to developers
>>> that the JDK does not have the EE components but from everything
>>> we've seen so far, then those EE components are usually on the class path 
>>> anyway.
>>
>> Ah ok, so this means that the problem has been punted to the other
>> foot i.e. the only apps affected will be those which i) don't have an
>> EE jar on their classpath and ii) require the (partial) stub
>> implementations provided by Java SE. That sounds much better since
>> such a configuration is of almost no use to anyone and hence is very 
>> unlikely to arise.
>
> Agreed: excellent idea!
>
> I'm eager to try it out so that we can resume testing of everything else too; 
> I just tried my luck with build 9-ea+114 but it didn't seem to work: I'm 
> going to assume this wasn't implemented yet, or should I double check how I'm 
> building?
> Did I understand correctly that I won't need to pass any switch to neither 
> java nor javac, as long as I have the JavaEE jar as external dependencies on 
> my classpath? (i.e. if this build is "proven" on Java8 it should work on 
> Java9 ?)
>
> Is there an issue tracker which I could follow to watch updates on this?
>
> Slightly unrelated, but is it expected that compilation is successful, even 
> though (in my specific case) javax.transaction.Synchronization causes a 
> java.lang.NoClassDefFoundError at runtime?
>
> Thanks,
> Sanne

Re: Root modules (was Re: JMH and JDK9)

[Alan Bateman]

On 22/04/2016 20:01, Sanne Grinovero wrote:

:
Thanks! Indeed, it's working great.

[tested 9-ea+114-2016-04-19-162931.javare.4880.nc]

Ironically this means we can make more progress testing using the
Jigsaw EA builds, while I'm completely blocked on the "mainline".



Thanks for confirming.

We expect the changes in jake to move into JDK 9 soon. There's a bit of 
coordination with the jtreg test harness that has to be worked out 
before this can happen.


-Alan

Re: The javax.annotation.Generated and annotation processors

[Alan Bateman]

On 22/04/2016 19:55, Sanne Grinovero wrote:

Hello all,

related to https://bugs.openjdk.java.net/browse/JDK-8152842

I'm having to patch our annotation processors to avoid the @Generated
annotation, as I can't use the proposed workaround to use `-addmods
java.annotations.common`: our build also requires `-target 1.7` and
the two options are not compatible.

But I hope this will be only very short term? I'm only working this
around temporarily so that I can keep testing other more interesting
aspects of Jigsaw, but ultimately we'll need that annotation back.

Thanks,
Sanne

There's two issues here.

One is that when you run `javac` then the you are essentially executing 
the jdk.compiler module. This module is resolved at startup and the 
transitively closure (+ services) is restricting the set of modules that 
can be read by your annotation processor (that is in its own unnamed 
module). We had a small update that we need to do in JEP 261 to support 
this and at the same time align with the updated policy on root modules 
when executing code in the unnamed module. So assume that `javac`, 
`javadoc` and several other tools will be updated with this soon.


The other issue is specific to the java.corba module and the 5 modules 
that are shared with Java EE. These are not resolved by default so this 
is why `-addmods` (or `-J-addmods` if javac -processor and the 
annotation processor needs the module to be resolved) is needed. In the 
other thread then you are happy that the EE version of Java Transaction 
API is located in preference to the subset in the JDK, in this case you 
want the Java SE subset of the Common Annotations. It's impossible to 
fix all cases without going back to split packages again.


On combing options then if you are compiling with `-target 1.7` then I 
assume you must be also specifying `-source 1.7` and `-bootclasspath 
...` and so `-addmods` isn't in the picture. Better still then `javac 
-release 7` should do it.


On the other hand, if this its the annotation processor using @Generated 
then I would expect this should work:

-J-addmods -Jjava.annotations.common -processor ... -release 7

The -J is the way to pass options through to the underlying runtime (or 
execution environment in javac speak).


-Alan

Re: The javax.annotation.Generated and annotation processors

[Sanne Grinovero]

On Fri, Apr 22, 2016 at 8:47 PM, Alan Bateman  wrote:
> On 22/04/2016 19:55, Sanne Grinovero wrote:
>>
>> Hello all,
>>
>> related to https://bugs.openjdk.java.net/browse/JDK-8152842
>>
>> I'm having to patch our annotation processors to avoid the @Generated
>> annotation, as I can't use the proposed workaround to use `-addmods
>> java.annotations.common`: our build also requires `-target 1.7` and
>> the two options are not compatible.
>>
>> But I hope this will be only very short term? I'm only working this
>> around temporarily so that I can keep testing other more interesting
>> aspects of Jigsaw, but ultimately we'll need that annotation back.
>>
>> Thanks,
>> Sanne
>
> There's two issues here.
>
> One is that when you run `javac` then the you are essentially executing the
> jdk.compiler module. This module is resolved at startup and the transitively
> closure (+ services) is restricting the set of modules that can be read by
> your annotation processor (that is in its own unnamed module). We had a
> small update that we need to do in JEP 261 to support this and at the same
> time align with the updated policy on root modules when executing code in
> the unnamed module. So assume that `javac`, `javadoc` and several other
> tools will be updated with this soon.
>
> The other issue is specific to the java.corba module and the 5 modules that
> are shared with Java EE. These are not resolved by default so this is why
> `-addmods` (or `-J-addmods` if javac -processor and the annotation processor
> needs the module to be resolved) is needed. In the other thread then you are
> happy that the EE version of Java Transaction API is located in preference
> to the subset in the JDK, in this case you want the Java SE subset of the
> Common Annotations. It's impossible to fix all cases without going back to
> split packages again.
>
> On combing options then if you are compiling with `-target 1.7` then I
> assume you must be also specifying `-source 1.7` and `-bootclasspath ...`
> and so `-addmods` isn't in the picture. Better still then `javac -release 7`
> should do it.
>
> On the other hand, if this its the annotation processor using @Generated
> then I would expect this should work:
> -J-addmods -Jjava.annotations.common -processor ... -release 7
>
> The -J is the way to pass options through to the underlying runtime (or
> execution environment in javac speak).

Thanks Alan for these explanations, your guidance is proving essential
while I'm falling deeper in this wonderland.

I can't use "-release 7" as our code needs to be built with JDK8 (at
least): it has support for dealing with the new Date/Time APIs from
Java8, yet it falls back gracefully to disable such functionality when
run on Java 7.
I realize that I have plenty of alternatives to break that in separate
units - but I'll spare you such off topic details.

It's good to know that other simpler projects should be able to
benefit from your above suggestions.

I couldn't try the "-J-addmods -Jjava.annotations.common" solution
either, I suspect because Maven is getting in the way and possibly
passing these parameters in the wrong order; for the record this is
the stack:

Caused by: java.lang.IllegalArgumentException: invalid flag: -J-addmods
at 
com.sun.tools.javac.main.Arguments.error(jdk.compiler@9-ea/Arguments.java:779)
at 
com.sun.tools.javac.main.Arguments.doProcessArgs(jdk.compiler@9-ea/Arguments.java:378)
at 
com.sun.tools.javac.main.Arguments.processArgs(jdk.compiler@9-ea/Arguments.java:294)
at 
com.sun.tools.javac.main.Arguments.init(jdk.compiler@9-ea/Arguments.java:250)
at 
com.sun.tools.javac.api.JavacTool.getTask(jdk.compiler@9-ea/JavacTool.java:175)
at 
com.sun.tools.javac.api.JavacTool.getTask(jdk.compiler@9-ea/JavacTool.java:109)
at 
com.sun.tools.javac.api.JavacTool.getTask(jdk.compiler@9-ea/JavacTool.java:65)
at 
org.bsc.maven.plugin.processor.AbstractAnnotationProcessorMojo.executeWithExceptionsHandled(AbstractAnnotationProcessorMojo.java:527)

But found a solution: your suggestion that this is a similar problem -
but opposite - then what I had with the Java EE APIs was spot on:
I simply added the API jar from jsr250 "javax.annotation" on the
classpath of the annotation processor and it's all working nicely.

I noticed something else which might be of interest. We build the
project in two distinct phases: annotation processor(s) first,
compilation second.
I'm surprised to see that the second phase is working fine even though
I did not add the jsr250 dependency; I didn't investigate further but
it seems like the compiler knows that this annotation is annotated
with "@Retention(SOURCE)" ?!

For those using Maven, I pasted an example of this solution here:
 - https://issues.jboss.org/browse/LOGTOOL-105?focusedCommentId=13196069

BTW all these questions I've been sending recently relate to a popular
open source project. If anyone would like to experiment with the same
projects it's available at
https://githu