Privileged module idea

[Nikita Lipsky]

Hi all,

 

Recently I have described an idea of "privileged module" --
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009636.ht
ml
  :

 

"privileged module" may reflect on any unexported (and exported) type of
other resolved modules of a layer that it belongs to.

DI/JPA frameworks are subjects for "privileged modules".

 

"Privileged module" moves responsibility of weakened strong
encapsulation from user modules (via weak module or dynamic export
concepts) to framework modules.

 

I would greatly appreciate if someone could give me any feedback on it.

 

Regards,

Nikita

 

hg: jigsaw/jake/langtools: 19 new changesets

[mandy . chung]

Changeset: 3dbcbc28ea1b
Author:jjg
Date:  2016-10-04 16:47 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3dbcbc28ea1b

8166472: javac/javadoc expands @files incorrectly
Reviewed-by: henryjen, ksrini

! src/jdk.compiler/share/classes/com/sun/tools/javac/main/CommandLine.java
+ test/tools/javac/main/AtFileTest.java

Changeset: 49314bc6d795
Author:smarks
Date:  2016-10-04 18:43 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/49314bc6d795

8161338: (jdeprscan) remove JEP 293 non-conforming -cp option
8165927: (jdeprscan) com.sun.tools.jdeprscan.Main.instance should be package 
protected
Reviewed-by: jjg

! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/readme.md
! 
src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan.properties
! test/tools/jdeprscan/tests/jdk/jdeprscan/TestScan.java

Changeset: a35a1d86165c
Author:mchung
Date:  2016-10-04 18:56 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a35a1d86165c

8166860: Add magic number to jmod file
Reviewed-by: alanb, jjg

! make/tools/crules/MutableFieldsAnalyzer.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java
! test/tools/javac/T8003967/DetectMutableStaticFields.java

Changeset: 076a0354bedb
Author:mcimadamore
Date:  2016-10-05 13:06 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/076a0354bedb

8167070: Performance regression in compound scopes
Summary: Extra call to inner scope's hasNext() causes performance regression
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Iterators.java

Changeset: 0eda7aaaf3d2
Author:mchung
Date:  2016-10-05 18:41 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0eda7aaaf3d2

8166846: jdeps fails to generate module info if there is any class in unnamed 
package
Reviewed-by: lancea

! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties
! test/tools/jdeps/jdkinternals/RemovedJDKInternals.java
! test/tools/jdeps/jdkinternals/ShowReplacement.java
+ test/tools/jdeps/lib/JdepsRunner.java
! test/tools/jdeps/lib/JdepsUtil.java
! test/tools/jdeps/modules/GenModuleInfo.java
+ test/tools/jdeps/modules/UnnamedPackage.java

Changeset: d7c3ad383ed5
Author:mchung
Date:  2016-10-05 18:42 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d7c3ad383ed5

8167014: jdeps: Missing message: warn.skipped.entry
Reviewed-by: alanb, lancea

! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties

Changeset: 53dd5c5efac3
Author:jlahoda
Date:  2016-10-06 14:03 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/53dd5c5efac3

8153362: Add javac -Xlint warning to list exposed types which are not accessible
Summary: Adding implementation to -Xlint:exports, to warn about exposing 
inaccessible types in API
Reviewed-by: jjg

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/LeaksNotAccessible/LeaksNotAccessible.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessible/modulesourcepath/m1/api/Api.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessible/modulesourcepath/m1/module-info.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/LeaksNotAccessibleNotRequiredPublic.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/modulesourcepath/m1/api1/Api1.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/modulesourcepath/m1/module-info.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/modulesourcepath/m2/api2/Api2.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleNotRequiredPublic/modulesourcepath/m2/module-info.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleUnexported/LeaksNotAccessibleUnexported.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleUnexported/modulesourcepath/m1/api/Api.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleUnexported/modulesourcepath/m1/impl/Impl.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleUnexported/modulesourcepath/m1/module-info.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleUnexportedQualified/LeaksNotAccessibleUnexportedQualified.java
+ 
test/tools/javac/diags/examples/LeaksNotAccessibleUnexportedQualified/modulesourcepath/m1/api/Api.java
+ 

hg: jigsaw/jake/hotspot: 74 new changesets

[mandy . chung]

Changeset: 15b3ef116f15
Author:erikj
Date:  2016-10-05 10:49 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/15b3ef116f15

8150736: Excessive disk space used by build system
Reviewed-by: ihse

! make/BuildHotspot.gmk
+ make/CopyToExplodedJdk.gmk
- make/Dist.gmk
! make/HotspotCommon.gmk
+ make/copy/Copy-java.base.gmk
! make/gensrc/GenerateSources.gmk
! make/gensrc/GensrcJvmti.gmk
! make/lib/CompileDtracePostJvm.gmk
! make/lib/CompileJvm.gmk
! make/lib/CompileLibjsig.gmk
! make/lib/CompileLibraries.gmk

Changeset: cc7606285d36
Author:erikj
Date:  2016-10-05 17:11 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cc7606285d36

8161025: GPL header missing comma in year
Reviewed-by: dholmes

! make/BuildHotspot.gmk

Changeset: 4d009502987b
Author:eosterlund
Date:  2016-09-20 11:41 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4d009502987b

8165860: WorkGroup classes are missing volatile specifiers for lock-free code
Reviewed-by: mgerdin, tschatzl

! src/share/vm/gc/shared/workgroup.cpp
! src/share/vm/gc/shared/workgroup.hpp

Changeset: a6dab42b58af
Author:bchristi
Date:  2016-09-20 10:04 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a6dab42b58af

8165372: StackWalker performance regression following JDK-8147039
Summary: Stack walking can use javaVFrame or vframeStream
Reviewed-by: coleenp, mchung

! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/stackwalk.cpp
! src/share/vm/prims/stackwalk.hpp

Changeset: d566fd6e0740
Author:ccheung
Date:  2016-09-20 10:37 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d566fd6e0740

8164011: --patch-module support for CDS
Summary: allows the use of the --patch-module vm option with CDS. However, 
classes found in --patch-module during dump time will not be archived.
Reviewed-by: iklam, dcubed, lfoltan

! src/share/vm/classfile/classLoader.cpp
! src/share/vm/classfile/classLoader.hpp
! src/share/vm/classfile/sharedPathsMiscInfo.cpp
! src/share/vm/classfile/sharedPathsMiscInfo.hpp
! src/share/vm/memory/filemap.cpp
! src/share/vm/memory/filemap.hpp
! src/share/vm/runtime/arguments.cpp
! test/runtime/modules/PatchModule/PatchModuleCDS.java

Changeset: 1c9533c9629a
Author:ccheung
Date:  2016-09-20 20:22 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1c9533c9629a

Merge


Changeset: 8fcdd3cc8da0
Author:eosterlund
Date:  2016-09-20 15:42 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8fcdd3cc8da0

8033552: Fix missing missing volatile specifiers in CAS operations in GC code
Summary: Add missing volatile specifiers.
Reviewed-by: kbarrett, tschatzl

! src/share/vm/gc/cms/cmsOopClosures.hpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc/g1/heapRegionRemSet.cpp
! src/share/vm/gc/g1/sparsePRT.cpp
! src/share/vm/gc/g1/sparsePRT.hpp
! src/share/vm/gc/parallel/mutableSpace.hpp
! src/share/vm/gc/parallel/parallelScavengeHeap.hpp
! src/share/vm/gc/parallel/psYoungGen.hpp
! src/share/vm/gc/parallel/vmStructs_parallelgc.hpp
! src/share/vm/gc/serial/defNewGeneration.cpp
! src/share/vm/gc/serial/defNewGeneration.hpp
! src/share/vm/gc/shared/collectedHeap.hpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
! src/share/vm/gc/shared/genCollectedHeap.hpp
! src/share/vm/gc/shared/generation.hpp
! src/share/vm/jvmci/jvmciCompilerToVM.cpp
! src/share/vm/jvmci/jvmciCompilerToVM.hpp
! src/share/vm/jvmci/vmStructs_jvmci.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: ab2b45b79d71
Author:jprovino
Date:  2016-09-20 10:27 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ab2b45b79d71

8164482: [REDO] G1 does not implement millis_since_last_gc which is needed by 
RMI GC
Summary: G1 does not return a correct value for the 
CollectedHeap::millis_since_last_gc()
Reviewed-by: tschatzl, kbarrett

! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1DefaultPolicy.cpp
! src/share/vm/gc/g1/g1DefaultPolicy.hpp
! src/share/vm/gc/g1/g1Policy.hpp
! src/share/vm/gc/shared/genCollectedHeap.cpp

Changeset: 53443835ee75
Author:jprovino
Date:  2016-09-20 20:45 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/53443835ee75

Merge

- test/serviceability/jdwp/JdwpModuleCmd.java
- test/serviceability/jdwp/JdwpModuleReply.java
- test/serviceability/jdwp/JdwpVisibleClassesCmd.java
- test/serviceability/jdwp/JdwpVisibleClassesReply.java

Changeset: ddb6b697fbd1
Author:jprovino
Date:  2016-09-20 22:38 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ddb6b697fbd1

Merge

! src/share/vm/gc/shared/genCollectedHeap.cpp

Changeset: c86a798296ae
Author:sspitsyn
Date:  2016-09-21 01:33 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c86a798296ae

8147943: jvmti.h generated with GPL header
Summary: Generate the jvmti.h with the GPL+CP header

hg: jigsaw/jake/jaxws: 4 new changesets

[mandy . chung]

Changeset: 9004617323fe
Author:iris
Date:  2016-10-06 18:05 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/9004617323fe

8166799: ASSEMBLY_EXCEPTION contains historical company name
Reviewed-by: mchung, tbell

! ASSEMBLY_EXCEPTION

Changeset: 848c3576bb50
Author:mchung
Date:  2016-10-13 15:37 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/848c3576bb50

Merge


Changeset: b2c18f755228
Author:lana
Date:  2016-10-13 21:01 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/b2c18f755228

Added tag jdk-9+140 for changeset 9004617323fe

! .hgtags

Changeset: 4bc497b0caef
Author:mchung
Date:  2016-10-13 17:24 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/4bc497b0caef

Merge

hg: jigsaw/jake: 19 new changesets

[mandy . chung]

Changeset: 278f9a9e9329
Author:erikj
Date:  2016-10-05 10:49 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/278f9a9e9329

8150736: Excessive disk space used by build system
Reviewed-by: ihse

! common/bin/compare.sh
! make/CopyImportModules.gmk
! make/CreateJmods.gmk
! make/Help.gmk
! make/Images.gmk
! make/Javadoc.gmk
! make/Main.gmk
! make/MainSupport.gmk
! make/ModuleWrapper.gmk
- make/StripBinaries.gmk
! make/common/MakeBase.gmk
! make/common/NativeCompilation.gmk
! make/common/TestFilesCompilation.gmk
! test/make/TestMakeBase.gmk

Changeset: 4bd1866d819b
Author:erikj
Date:  2016-10-05 17:10 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/4bd1866d819b

8161018: GPL header missing comma in year
Reviewed-by: dholmes

! make/common/TextFileProcessing.gmk

Changeset: 80ae3a250bd8
Author:iignatyev
Date:  2016-09-22 15:40 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/80ae3a250bd8

8166483: gtest fmw should be updated to support null detection on SS >= 12u4
Reviewed-by: dholmes, kzhaldyb

! test/fmw/gtest/include/gtest/internal/gtest-port.h

Changeset: d45240297def
Author:amurillo
Date:  2016-09-23 13:44 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/d45240297def

Merge


Changeset: a85b22ed4fc8
Author:goetz
Date:  2016-09-01 16:46 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/a85b22ed4fc8

8165235: [TESTBUG] RTM tests must check OS version
Reviewed-by: simonis, fzhinkin

! test/lib/jdk/test/lib/Platform.java
! test/lib/jdk/test/lib/cli/predicate/AndPredicate.java

Changeset: 88c6c6fbc171
Author:dlong
Date:  2016-09-20 16:34 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/88c6c6fbc171

Merge

! test/lib/jdk/test/lib/Platform.java
- test/lib/jdk/test/lib/unsafe/UnsafeHelper.java

Changeset: e4c5488bfc95
Author:dlong
Date:  2016-09-26 14:21 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/e4c5488bfc95

Merge


Changeset: 40c4c2e2cdf3
Author:dlong
Date:  2016-09-27 20:57 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/40c4c2e2cdf3

Merge


Changeset: c623a5f16cf0
Author:amurillo
Date:  2016-09-30 02:52 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/c623a5f16cf0

Merge


Changeset: 22376945f80f
Author:amurillo
Date:  2016-10-05 06:28 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/22376945f80f

Merge

- make/StripBinaries.gmk

Changeset: a902e9316e39
Author:amurillo
Date:  2016-10-05 09:52 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/a902e9316e39

Merge


Changeset: 81435a812f59
Author:jlahoda
Date:  2016-10-06 14:03 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/81435a812f59

8153362: Add javac -Xlint warning to list exposed types which are not accessible
Summary: Disabling exports lint (newly introduced to javac) on java.desktop, 
java.naming, jdk.accessibility, jdk.jshell, jdk.jsobject, jdk.security.jgss, 
jdk.vm.ci
Reviewed-by: alanb

! make/CompileJavaModules.gmk

Changeset: ae8544c57879
Author:lana
Date:  2016-10-06 23:12 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/ae8544c57879

Merge

- make/StripBinaries.gmk

Changeset: 3f4fc8ef367c
Author:weijun
Date:  2016-10-07 07:59 +0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/3f4fc8ef367c

8167181: Exported elements referring to inaccessible types in jdk.security.jgss
Reviewed-by: mchung

! make/CompileJavaModules.gmk

Changeset: d7344d658f7e
Author:iris
Date:  2016-10-06 18:06 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/d7344d658f7e

8166799: ASSEMBLY_EXCEPTION contains historical company name
Reviewed-by: mchung, tbell

! ASSEMBLY_EXCEPTION

Changeset: a5815c6098a2
Author:erikj
Date:  2016-10-07 09:11 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/a5815c6098a2

8167195: VM fails to initialize intermittently when running jmod to create some 
images
Reviewed-by: tbell, mchung

! make/Main.gmk

Changeset: c7dced0d7ee9
Author:mchung
Date:  2016-10-13 15:37 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/c7dced0d7ee9

Merge

! common/bin/compare.sh
! make/CompileJavaModules.gmk
! make/CopyImportModules.gmk
! make/CreateJmods.gmk
! make/Images.gmk
! make/Javadoc.gmk
! make/Main.gmk
! make/MainSupport.gmk
! make/ModuleWrapper.gmk
! make/common/MakeBase.gmk
! make/common/NativeCompilation.gmk

Changeset: d174e5c2f53b
Author:lana
Date:  2016-10-13 21:01 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/d174e5c2f53b

Added tag jdk-9+140 for changeset a5815c6098a2

! .hgtags

Changeset: aafa4438e043
Author:mchung
Date:  2016-10-13 17:24 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/aafa4438e043

Merge

hg: jigsaw/jake/corba: 4 new changesets

[mandy . chung]

Changeset: 9f3fc931bc23
Author:iris
Date:  2016-10-06 18:05 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/9f3fc931bc23

8166799: ASSEMBLY_EXCEPTION contains historical company name
Reviewed-by: mchung, tbell

! ASSEMBLY_EXCEPTION

Changeset: 0108af3fc8f8
Author:mchung
Date:  2016-10-13 15:37 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/0108af3fc8f8

Merge


Changeset: 79b8a48ab41a
Author:lana
Date:  2016-10-13 21:01 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/79b8a48ab41a

Added tag jdk-9+140 for changeset 9f3fc931bc23

! .hgtags

Changeset: 77603fba042e
Author:mchung
Date:  2016-10-13 17:24 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/77603fba042e

Merge

Re: [9] RfR: 8165271: Fix use of reflection to gain access to private fields

[Mandy Chung]

> On Oct 13, 2016, at 4:08 PM, David DeHaven  wrote:
> 
> 
> JBS Issue:
> https://bugs.openjdk.java.net/browse/JDK-8165271
> 
> Webrev:
> http://cr.openjdk.java.net/~ddehaven/8165271/jdk.0/

This change looks fine.  This hack should have been replaced long ago and happy 
to see them gone.

Mandy

[9] RfR: 8165271: Fix use of reflection to gain access to private fields

[David DeHaven]

JBS Issue:
https://bugs.openjdk.java.net/browse/JDK-8165271

Webrev:
http://cr.openjdk.java.net/~ddehaven/8165271/jdk.0/

Synopsis:
An upcoming change in the module system will prevent setAccessible calls from 
working across module boundaries. This patch allows the use of SharedSecrets 
instead to preserve the underlying logic.

-DrD-

hg: jigsaw/jake/jdk: 3 new changesets

[mandy . chung]

Changeset: 6877e9efabf0
Author:redestad
Date:  2016-10-13 17:00 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6877e9efabf0

Use Set.of for ModuleDescriptor.requires and exports
Reviewed-by: mchung, alanb

! src/java.base/share/classes/jdk/internal/module/Builder.java
! 
src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java

Changeset: 54e7c87386e0
Author:mchung
Date:  2016-10-13 15:36 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/54e7c87386e0

Minor adjustment to SystemModuleDescriptorPlugin

! src/java.base/share/classes/jdk/internal/module/Builder.java
! 
src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java

Changeset: 5a042e9dd0b0
Author:mchung
Date:  2016-10-13 15:37 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5a042e9dd0b0

Merge

Re: Problem with multi-release jars, agents and the bootstrap class path

[Andrew Dinn]

On 13/10/16 18:27, Alan Bateman wrote:
> What you see is deliberate. It wouldn't be impossible for the boot
> loader to support MR JARs but it hardly seems worth the complexity. One
> reason is that it's not a common way to deploy a general purpose
> library. Even if it were then it would be problematic going forward as
> we reduce the number of modules defined to the boot loader (you can't
> instrument code in core modules to call into a SQL library for example
> because java.sql types are not visible to code in the boot loader). The
> other thing is that the boot class path as we used to know it is mostly
> gone, it only really exists when using -Xbootclasspath/a or when JVM TI
> or java.lang.instrument do the equivalent.

Ok, that's what I was expecting to be the answer :-)

I am aware that the code I add to the bootstrap can only rely on a core
subset of the JDK runtime classes being available. That ought not to be
an issue -- I have deliberately kept the agent's footprint as small as
possible because every time Byteman uses an API it makes it trickier to
instrument the API class. I'd be interested to know what you are hoping
to exclude though, just in case. Am I ok with print stream? file
streams? localhost server sockets? Just checking :-)

> For the "hoist"-ing scenario then I assume you mean
> Instrumentation::appendToBootstrapClassLoaderSearch to add supporting
> classes to the boot class path so that they are visible to instrumented
> code. Can you use the same method to append a JAR file containing
> 53.0/9+ classes before you append the other JAR. That should be
> equivalent to what a MR JAR would give you, albeit without the
> convenience of everything in one artifact.

Yes, by hoisting I mean precisely that. The minor wrinkle that the class
which adds the agent jar to the bootstrap path actually gets loaded from
that same jar (but via the system classpath) is what led me to use  the
term 'hoist'. There is probably a joke in here somewhere about 'my own
petard' but I'll demur.

I could indeed use two jar files -- in fact my last attempt at a JDK9
compatible implementation did precisely that. However, that actually
turns out to be /much/ more inconvenient because it means the agent jar
doing the hoisting needs to be able to work out where the auxiliary jar
is. This results in a lot of configuration grief (because of the need to
cope with command line vs dynamic install and also to make it easy to do
from tools like maven). So I much prefer a one jar solution.

As it happens, I have managed to encapsulate the JDK8- vs JDK9+ variant
functionality behind an interface. This means that I ham able to employ
just one setup class which needs a JDK8- and JDK9+ variant -- it's job
is to provide a static method which populates the interface with a
suitable implementation. So, I /can/ actually resolve this issue by
bundling all the code in one jar but with this variant implemented as
two distinct classes. I will simply load the relevant variant by name +
reflectively invoke it's static setup method conditional on whether or
not the JDK includes Jigsaw.

I was asking not because this problem is not resolvable but because

  I thought the multi-release option was a very neat solution that I
really ought to try to use

  I envisaged that other agent implementors might not find it so easy to
encapsulate the required functionality

It's a shame multi-release won't work for all agents but never mind.

Thanks very much for the quick and helpful response.

regards,


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

hg: jigsaw/jake/hotspot: 8167487: Remove unused module related JVM API's

[harold . seigel]

Changeset: 3b0fd4bfd0a4
Author:hseigel
Date:  2016-10-13 13:03 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3b0fd4bfd0a4

8167487: Remove unused module related JVM API's
Summary: Remove JVM_CanReadModule() and JVM_IsExportedToModule()and the 
functions that only they call.
Reviewed-by: lfoltan

! make/symbols/symbols-unix
! src/share/vm/classfile/modules.cpp
! src/share/vm/classfile/modules.hpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvm.h
! src/share/vm/prims/whitebox.cpp
- test/runtime/modules/JVMCanReadModule.java
- test/runtime/modules/JVMIsExportedToModule.java
! test/runtime/modules/ModuleHelper.java

hg: jigsaw/jake: 8167487: Remove unused module related JVM API's

[harold . seigel]

Changeset: 77577e358ec2
Author:hseigel
Date:  2016-10-13 13:02 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/77577e358ec2

8167487: Remove unused module related JVM API's
Summary: Remove JVM_CanReadModule() and JVM_IsExportedToModule()and the 
functions that only they call.
Reviewed-by: lfoltan

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

Re: Problem with multi-release jars, agents and the bootstrap class path

[Alan Bateman]

On 13/10/2016 17:40, Andrew Dinn wrote:


:


A Few Questions:

Am I right that this is a deliberate choice of bootstrap loader
behaviour? Or is there perhaps some other bug here?

If this is a deliberate choice is there any possibility of reviewing it?

Would it be particularly difficult to modify the boot loader to
recognise jars in multi-release format?


What you see is deliberate. It wouldn't be impossible for the boot 
loader to support MR JARs but it hardly seems worth the complexity. One 
reason is that it's not a common way to deploy a general purpose 
library. Even if it were then it would be problematic going forward as 
we reduce the number of modules defined to the boot loader (you can't 
instrument code in core modules to call into a SQL library for example 
because java.sql types are not visible to code in the boot loader). The 
other thing is that the boot class path as we used to know it is mostly 
gone, it only really exists when using -Xbootclasspath/a or when JVM TI 
or java.lang.instrument do the equivalent.


For the "hoist"-ing scenario then I assume you mean 
Instrumentation::appendToBootstrapClassLoaderSearch to add supporting 
classes to the boot class path so that they are visible to instrumented 
code. Can you use the same method to append a JAR file containing 
53.0/9+ classes before you append the other JAR. That should be 
equivalent to what a MR JAR would give you, albeit without the 
convenience of everything in one artifact.


-Alan

Re: Ugly things done to support multiple ContentHandlerFactory and URLStreamHandlerFactory

[Alan Bateman]

On 13/10/2016 17:23, Thomas Watson wrote:


:

Thanks for the pointer Alan.  I'll have a look.  Is there any 
additional documentation on this besides the javadoc?  At first glance 
it is unclear to me what discovers the providers?  Is the the URL 
class itself based on the thread context class loader?  How do 
providers interact with the statically set factory.  I also don't see 
a provider SPI type for java.net.ContentHandlerFactory.
The javadoc for the 4-arg URL constructor has all the details on how it 
interacts with the system-wide stream handler factory, also how the 
system class loader is used to locate protocol handlers that are 
intended to used system-wide (this includes the ability to override 
non-core protocol handlers).  I've no doubt that this won't be exactly 
what you want but I hope you can see how URLStreamHandlerProvider is 
used as the service type.


There are also updates to allow ContentHandlerFactory implementations be 
deployed as modules. The details on that are in the javadoc for 
URLConnection::getContent. This one did not need introducing a new 
service type.


-Alan.

Problem with multi-release jars, agents and the bootstrap class path

[Andrew Dinn]

Disclaimer:

Although this post relates to handling of multi-release jars I'm
cross-posting to jigsaw-dev as well as core-libs-dev. That's because the
problem arises only because my JVMTI Java agent now needs to operate in
dual mode to cope with Jigsaw when deployed on JDK9+ and to avoid
reference to Jigsaw when deployed on JDK8-, hence the desire to use the
multi-release format. Apologies if the cross-post is redundant.

The Problem:

I have re-packaged my Byteman JVMTI Java agent using a multi-release jar
format so that it can operate as is on JDK8- (compiled as target 6 and
no reference to Jigsaw code) while providing revised functionality on
JDK9 that accounts for the presence of modules. This works fine if I
deploy the agent on the system classpath.

However, for some modes of operation my agent Main class hoists the
agent jar into the bootstrap classpath. This is needed so that I can
inject references to agent classes into JDK bootstrap code like Thread
etc. The problem is that bootstrap loader does not appear to recognise
that the jar is in multi-release format.

I can understand that this may seem to be an appropriate behaviour under
the assumption that code in the bootstrap ought to be the JDK runtime
code and therefore ought to be compiled at the current JDK/JVM version.
However, that assumption doesn't really hold when the code in question
is an agent which may well need to operate on old and new JDK versions.


A Few Questions:

Am I right that this is a deliberate choice of bootstrap loader
behaviour? Or is there perhaps some other bug here?

If this is a deliberate choice is there any possibility of reviewing it?

Would it be particularly difficult to modify the boot loader to
recognise jars in multi-release format?

Thanks in advance!

regards,


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

Re: Ugly things done to support multiple ContentHandlerFactory and URLStreamHandlerFactory

[Thomas Watson]

> From: Alan Bateman 
> Have you looked at the changes in this area in JDK 9, specifically the 
> changes on how protocol handlers are located and the new URL stream 
> handler service-provider type URLStreamHandlerProvider?
> 
> -Alan
> 

Thanks for the pointer Alan.  I'll have a look.  Is there any additional 
documentation on this besides the javadoc?  At first glance it is unclear 
to me what discovers the providers?  Is the the URL class itself based on 
the thread context class loader?  How do providers interact with the 
statically set factory.  I also don't see a provider SPI type for 
java.net.ContentHandlerFactory.

Tom

Re: Ugly things done to support multiple ContentHandlerFactory and URLStreamHandlerFactory

[Alan Bateman]

On 13/10/2016 16:46, Thomas Watson wrote:

If not, are there going to be command line options that will allow us
to open up deep reflection of specific VM types as a compatibility mode
until we can get a proper solution?

There is a command-line option, in this case `--add-exports-private 
java.base/java.net=ALL-UNNAMED` will allow code on the class path (or 
any custom class loader) to continue to break into non-public members of 
java.net.URL or other types in this package.


-Alan

Ugly things done to support multiple ContentHandlerFactory and URLStreamHandlerFactory

[Thomas Watson]

Now that jigsaw is prohibiting deep reflection on types provided by the 
boot modules we are running into an issue with the ugly things we do [1] 
in order to support multiple factories in Equinox (an OSGi 
implementation).  Each Equinox instance has its own context aware 
ContentHandlerFactory and URLStreamHandlerFactory which serves up handlers 
that are available for the particular instance of Equinox.  In order to do 
this we have to resort to some very ugly reflection.  This allows us to 
gain access to the 'base' factory object set in the VM so that each 
instance of the framework can register itself with the 'base' factory. The 
'base' factory handlers do the complicated work of figuring out which 
factory to call based on the context which is calling the base handler.

We also resort to reflection on framework shutdown in order to flush our 
factories out from the VM so that the base factory is not pinning our 
framework in memory.  I am also aware that the Apache Felix OSGi Framework 
implementation uses similar deep reflection in its implementation.  Are 
there any plans in Java 9 that will make this scenario easier to achieve 
without resorting to the use of deep reflection on the URL types from the 
VM?  If not, are there going to be command line options that will allow us 
to open up deep reflection of specific VM types as a compatibility mode 
until we can get a proper solution?

At a minimum I think we need someway to unset the statically set handlers 
in the VM to avoid pinning our base factories.  I can think of other 
non-reflective ways to gain access to the base handler instance in order 
to register each framework instance with the base handler.  For example, 
the base factory could implement a specific protocol which allows a 
connection to register another framework.

But we are still left with a delima of how to wrap the handlers returned 
by various framework factory instances from the base handlers.  All the 
interesting methods on java.net.URLStreamHandler are protected.  Even 
though the proxy base handler extends java.net.URLStreamHandler it is not 
allowed to call the protected methods on another instance of 
java.net.URLStreamHandler.  We resorted to deep reflection on the 
java.net.URLStreamHandler class methods to do that.  The 
java.net.URLStreamHandler class is not an interface so we cannot easily 
create proxy classes using java.lang.reflect.Proxy.

Tom

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=502209

hg: jigsaw/jake/hotspot: 8167511: IgnoreModulePropertiesTest.java needs update for JDK-8162401

[mandy . chung]

Changeset: 7f5f6554f780
Author:mchung
Date:  2016-10-13 08:00 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7f5f6554f780

8167511: IgnoreModulePropertiesTest.java needs update for JDK-8162401
Reviewed-by: lfoltan, hseigel

! test/runtime/modules/IgnoreModulePropertiesTest.java

hg: jigsaw/jake/jdk: 4 new changesets

[alan . bateman]

Changeset: a16577fe3fb8
Author:alanb
Date:  2016-10-12 08:48 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a16577fe3fb8

Fixed typo in SL spec

! src/java.base/share/classes/java/util/ServiceLoader.java

Changeset: 5f031a97813b
Author:alanb
Date:  2016-10-12 09:36 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5f031a97813b

Temporary fix to allow access to protected static members

! src/java.base/share/classes/jdk/internal/reflect/Reflection.java

Changeset: 2fcefe594fc3
Author:alanb
Date:  2016-10-12 15:34 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2fcefe594fc3

Remove java/beans/XMLEncoder tests from exclude list

! test/ProblemList.txt

Changeset: 7bbd64a241bc
Author:alanb
Date:  2016-10-12 16:09 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7bbd64a241bc

java/rmi/transport/dgcDeadLock/DGCDeadLock.java failing

! test/ProblemList.txt
! test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java

hg: jigsaw/jake/hotspot: JVMTI AddModuleExportsPrivate not implemented

[alan . bateman]

Changeset: c94a89bcee37
Author:sspitsyn
Date:  2016-10-13 14:20 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c94a89bcee37

JVMTI AddModuleExportsPrivate not implemented

! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/prims/jvmti.xml
! src/share/vm/prims/jvmtiEnv.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/jvmtiExport.hpp
! test/serviceability/jvmti/AddModuleExports/libAddModuleExportsTest.c

Re: RFR 8167614: Avoid module dependency from jdk.dynalink to jdk.internal.module of java.base module

[Attila Szegedi]

Looks good to me, +1.

It seems correct that it’s the responsibility of the users of Dynalink to add 
the read edges from their own modules.

Attila.

> On 12 Oct 2016, at 18:31, Sundararajan Athijegannathan 
>  wrote:
> 
> Updated nashorn webrev:
> http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.01/
> 
> Changed to use Layer.boot().findModule.
> 
> Thanks
> 
> -Sundar
> 
> 
> On 10/12/2016 9:42 PM, Alan Bateman wrote:
>> On 12/10/2016 16:33, Sundararajan Athijegannathan wrote:
>> 
>>> :
>>> 
>>> Dynalink used to automatically add those necessary add edges. With the
>>> current change, nashorn adds necessary read edges. CallerSensitive
>>> methods are found only in java.base, java.logging, java.sql and
>>> java.sql.rowset modules - the first two are always present [in nashorn's
>>> compact1 dependency world]. The later two are checked for presence and
>>> read-edges are added conditionally (see ScriptLoader.java changes).
>> JDK-8154346 tracks fixing java.sql.DriverManager, there are
>> compatibility concerns to changing it but it is being looked at.
>> 
>> I'm not familiar with the issue in the java.sql.rowset module but it
>> may be that the security checks in SerialJavaObject::getFields can be
>> re-visited (I don't know all the history on that).
>> 
>> 
>>> 
>>> Yes, I need boot layer modules only and I'll change that.
>>> 
>> Thanks.
>> 
>> -Alan.
> 

Re: RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs

[Alan Bateman]

On 13/10/2016 00:00, Steve Drach wrote:


Hi,

Please review the latest webrev for this issue.

issue: https://bugs.openjdk.java.net/browse/JDK-8156499 

webrev: http://cr.openjdk.java.net/~sdrach/8156499/webrev.03/ 


I believe this changeset resolves all the issues Alan and Mandy had with the 
previous changesets.  They are:

1. the test silently passes if java.base.jmod can not be found on the 
module-path
2. the test assures that
 a. the correct module-info class is in the module image
 b. the correct resource file is in the module image
 c. the correct class file is in the module image
3. As before, the image module created is for the Runtime.Version of jlink.  
This demonstrates that MMR jar files
 are handled correctly, but will have to be updated to create an image 
based on the Runtime.Version of java.base
 when the appropriate code is migrated from jake.

In JarArchive::entries then you filter out META-INF/MANIFEST.MF and I'm 
not sure that that is right (think modular JAR on the module path with a 
manifest, it's just a resource file). Are directories the only case 
where toEntry can return null, in which case would it simpler to filter 
out directories here.


There is quite a bit of clean-up needed in this area (pre-dates your 
patch of course). Not clear why Archive isn't a Closeable for example, 
or why covariant returns aren't used by the more specialized 
JarArchive/JarEntry/etc. I'm sure you don't want to get into that but 
maybe we could at least make the JarFile available via a protected 
method rather than a field.


I don't have time just now to go through the test in detail but having 
it pass silently when on exploded build (no packaged modules) looks right.


-Alan