hg: jigsaw/jake/hotspot: Add @ignore to failing JVMCI tests until JDK-8143238 has been resolved

[christian . tornqvist]

Changeset: 1bd1e18ccdb0
Author:ctornqvi
Date:  2015-12-03 03:55 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1bd1e18ccdb0

Add @ignore to failing JVMCI tests until JDK-8143238 has been resolved

! test/compiler/jvmci/JVM_GetJVMCIRuntimeTest.java
! test/compiler/jvmci/SecurityRestrictionsTest.java
! test/compiler/jvmci/compilerToVM/AllocateCompileIdTest.java
! test/compiler/jvmci/compilerToVM/CanInlineMethodTest.java
! test/compiler/jvmci/compilerToVM/CollectCountersTest.java
! test/compiler/jvmci/compilerToVM/DebugOutputTest.java
! test/compiler/jvmci/compilerToVM/DoNotInlineOrCompileTest.java
! test/compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest.java
! test/compiler/jvmci/compilerToVM/FindUniqueConcreteMethodTest.java
! test/compiler/jvmci/compilerToVM/GetBytecodeTest.java
! test/compiler/jvmci/compilerToVM/GetClassInitializerTest.java
! test/compiler/jvmci/compilerToVM/GetConstantPoolTest.java
! test/compiler/jvmci/compilerToVM/GetExceptionTableTest.java
! test/compiler/jvmci/compilerToVM/GetImplementorTest.java
! test/compiler/jvmci/compilerToVM/GetLineNumberTableTest.java
! test/compiler/jvmci/compilerToVM/GetLocalVariableTableTest.java
! test/compiler/jvmci/compilerToVM/GetMaxCallTargetOffsetTest.java
! test/compiler/jvmci/compilerToVM/GetNextStackFrameTest.java
! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodAtSlotTest.java
! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodTest.java
! test/compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java
! test/compiler/jvmci/compilerToVM/GetStackTraceElementTest.java
! test/compiler/jvmci/compilerToVM/GetSymbolTest.java
! test/compiler/jvmci/compilerToVM/GetVtableIndexForInterfaceTest.java
! test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java
! test/compiler/jvmci/compilerToVM/HasFinalizableSubclassTest.java
! test/compiler/jvmci/compilerToVM/InitializeConfigurationTest.java
! test/compiler/jvmci/compilerToVM/IsMatureTest.java
! test/compiler/jvmci/compilerToVM/JVM_RegisterJVMCINatives.java
! test/compiler/jvmci/compilerToVM/LookupKlassInPoolTest.java
! test/compiler/jvmci/compilerToVM/LookupTypeTest.java
! test/compiler/jvmci/compilerToVM/MethodIsIgnoredBySecurityStackWalkTest.java
! test/compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java
! test/compiler/jvmci/compilerToVM/ReprofileTest.java
! test/compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java
! test/compiler/jvmci/compilerToVM/ResolveMethodTest.java
! test/compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java
! test/compiler/jvmci/compilerToVM/ShouldDebugNonSafepointsTest.java
! test/compiler/jvmci/compilerToVM/ShouldInlineMethodTest.java
! test/compiler/jvmci/events/JvmciCreateMetaAccessContextTest.java
! test/compiler/jvmci/events/JvmciNotifyInstallEventTest.java
! test/compiler/jvmci/events/JvmciShutdownEventTest.java
! 
test/compiler/jvmci/jdk.vm.ci.options.test/src/jdk/vm/ci/options/test/NestedBooleanOptionValueTest.java
! 
test/compiler/jvmci/jdk.vm.ci.options.test/src/jdk/vm/ci/options/test/TestOptionValue.java
! 
test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ConstantTest.java
! 
test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java
! 
test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveConcreteMethodTest.java
! 
test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveMethodTest.java
! 
test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestConstantReflectionProvider.java
! 
test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaField.java
! 
test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaMethod.java
! 
test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaType.java
! 
test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestMetaAccessProvider.java
! 
test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java
! 
test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java
! 
test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java

Re: JVMTI and instrumentation

[Alan Bateman]

On 03/12/2015 11:31, Michael Rasmussen wrote:

:
Well, you've always had to be very careful loading classes before VMInit,
you had to be really careful not to use things that wasn't initialized
yet. I don't see why it was felt neccesary to completely block the CFLM
events for these classes, making it hard to fully instrument the bootstrap
classes without having to do it in two passes, and supplying -Xpatch.

Also, last I checked, when java.base is defined in the VM, it's verified
that only packages from java.base has been defined so far, and if not it
is a fatal error; so even if someone tried to load a class outside of
java.base, that verification would kick in, and the VM would halt.

"Agents can use GetLoadedClasses function to generate the missed events"
doesn't really solve the problem. Yes, you can retransform the classes
afterwards, but that limits you to only change method bodies, thus cannot
add members to the classes.
As I said, I think will be possible once there is support for "module 
aware" agents. That piece just isn't there yet. It may require a new 
capability or maybe a new JVM TI phase, it will minimally require at 
least some specification changes. A module aware agent should be able to 
deal with CFLH events for classes loaded early in the startup but 
existing agents may not -- consider an agent that uses the CFLH to 
instrument code today to call into its own supporting library. Even if 
the supporting class could be loaded then it will fail immediately 
because it won't be able to link to its super-type, not even 
java.lang.Object because java.base has no exported packages in early 
startup. I'm guessing you are working around some of this by adding to 
or patching java.base.




:
Considering you also recently removed the system property "sun.boot.class
.path" (which is now live in the b94 build that just became available for
download), it would be very appreciated if an option were added back to
the JVM TI, so we have some way of either telling the VM to use this
patch dir/jar/jimage, and also be able to get CFLH events for classes
being loaded during primordial phase as well.

sun.boot.class.path is finally removed. It's value has been useless for 
a long time but the actual removal required several steps. The removal 
of this property shouldn't impact JVM TI AddToBootstrapClassLoaderSearch 
or -Xbootclasspath/a.


Is -Xpatch working for you? Can you use this in conjunction with 
-agentlib/-agentpath until there is further progress in this area.


-Alan

Re: JVMTI and instrumentation

[Michael Rasmussen]

On 2 December 2015 at 15:31, Alan Bateman  wrote:
> "JVM TI agents can no longer instrument Java code that runs early in the
> startup of the run-time environment. The vm start event is not sent until
> the module system is initialized, so JVM TI agents that do load-time
> instrumentation will not receive ClassFileLoadHook events for classes
> loaded during startup and they will also miss some previously-received
> CompiledMethodLoad and DynamicCodeGenerated events. Agents can use the
> GetLoadedClasses function to get the list of loaded classes and the
> GenerateEvents function to generate missed events. (Java agents will
> continue to function as before, since they run only during the live phase.)"
>
> So you won't see CFLH events until the Start phase.
>
> I think this can be re-visited once there is support for "module aware"
> agents. The important thing that agents will not be able to load classes
> outside the java.base module until the module system has been initialized.

Well, you've always had to be very careful loading classes before VMInit,
you had to be really careful not to use things that wasn't initialized
yet. I don't see why it was felt neccesary to completely block the CFLM
events for these classes, making it hard to fully instrument the bootstrap
classes without having to do it in two passes, and supplying -Xpatch.

Also, last I checked, when java.base is defined in the VM, it's verified
that only packages from java.base has been defined so far, and if not it
is a fatal error; so even if someone tried to load a class outside of
java.base, that verification would kick in, and the VM would halt.

"Agents can use GetLoadedClasses function to generate the missed events"
doesn't really solve the problem. Yes, you can retransform the classes
afterwards, but that limits you to only change method bodies, thus cannot
add members to the classes.

> Just on steps to update these APIs for modules then we should have an
> initial patch soon to help debugger agents. This has wider scope because
> it requires updates to JVM TI, JDWP and JDI. We need to work on
> instrumentation support too so use-cases, examples, and working with us
> to get this right would be great.

Considering you also recently removed the system property "sun.boot.class
.path" (which is now live in the b94 build that just became available for
download), it would be very appreciated if an option were added back to
the JVM TI, so we have some way of either telling the VM to use this
patch dir/jar/jimage, and also be able to get CFLH events for classes
being loaded during primordial phase as well.

/Michael

Re: JVMTI and instrumentation

[Michael Rasmussen]

On 3 December 2015 at 14:08, Alan Bateman  wrote:
> I'm guessing you are working around some of this by adding to or
> patching java.base.
> (...)
> Is -Xpatch working for you? Can you use this in conjunction with
> -agentlib/-agentpath until there is further progress in this area.

Correct, at the moment I'm patching java.base, adding the support classes
that are used during primordial phase so they appear as part of java.base

As mentioned earlier, the purpose of our native agent is basically to
simplify all this for the user, so it takes care of generating the patch
(when needed), adding the patch to the VM, so the patched classes are
loaded, and finally attach a javaagent, which then does the actual
work for the rest of the uptime.
Having to tell the user to just add an -agentpath JVM option, is simpler
than having detailed instructions that differs from JVM version to JVM
version, or even vendor to vendor.

Doing the individual steps, by building the patch, and then running
with -javaagent and -Xpatch (tested with b86), I am currently able to
get this running. I can mention that the project in question is JRebel,
and with the above steps, I can successfully reload classes.

Also, a side note:
My comments in the original mail regarding AddToBootstrapClassLoaderSearch
not working as indended, seemed to stem from it being corrupted because
I was changing the "sun.boot.class.path" property as well. A quick glance
in the code made it look like it was an issue with an internal index that
pointed to where in the boot class path new stuff should be appended to,
but changing the property directly didn't update the index, so it got
corrupted when both were called -- but since that property is no longer
available that issue is kind of moot now. Although, I haven't tested or
looking into if changing the "jdk.boot.class.path.append" property directly
have the same corruption issues?

/Michael

hg: jigsaw/jake/nashorn: 26 new changesets

[erik . joelsson]

Changeset: aad920be350a
Author:ihse
Date:  2015-06-11 00:23 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/aad920be350a

8085822: JEP 223: New Version-String Scheme (initial integration)
Reviewed-by: erikj, dcubed, dholmes, alanb, sundar
Contributed-by: Magnus Ihse Bursie 

! make/BuildNashorn.gmk
! make/build.xml
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Version.java
- 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template
+ 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties.template

Changeset: 3fc9a15406c9
Author:ihse
Date:  2015-06-11 00:50 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/3fc9a15406c9

Merge

! make/build.xml

Changeset: 364d69b6e2aa
Author:iris
Date:  2015-06-29 11:28 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/364d69b6e2aa

Merge

- 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template

Changeset: f412a1917841
Author:iris
Date:  2015-07-06 11:49 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f412a1917841

Merge

- 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template

Changeset: e25f6f6b1bdc
Author:iris
Date:  2015-07-13 13:24 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e25f6f6b1bdc

Merge

! make/BuildNashorn.gmk
! make/build.xml
- 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template

Changeset: 41ab26713b91
Author:iris
Date:  2015-07-20 11:02 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/41ab26713b91

Merge

- 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template

Changeset: cf83ed75d1dc
Author:iris
Date:  2015-07-23 13:20 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/cf83ed75d1dc

Merge

- 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template

Changeset: d46483bac1f6
Author:iris
Date:  2015-08-03 09:26 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/d46483bac1f6

Merge

! make/build.xml
- 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template

Changeset: 4949ab6748df
Author:iris
Date:  2015-08-17 13:03 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/4949ab6748df

Merge

- 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template

Changeset: 77646e19bd81
Author:iris
Date:  2015-08-25 14:45 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/77646e19bd81

Merge

! make/BuildNashorn.gmk
! make/build.xml
- 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template

Changeset: c085b63b8958
Author:iris
Date:  2015-08-31 13:57 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c085b63b8958

Merge

- 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template

Changeset: 07f769cf2a77
Author:iris
Date:  2015-09-08 10:25 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/07f769cf2a77

Merge

- 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template

Changeset: 4bd262720f39
Author:iris
Date:  2015-09-14 09:47 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/4bd262720f39

Merge

- 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template

Changeset: 254acef85541
Author:iris
Date:  2015-09-21 20:09 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/254acef85541

Merge

! make/BuildNashorn.gmk
- 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template

Changeset: 386f776e8921
Author:iris
Date:  2015-09-29 11:46 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/386f776e8921

Merge

- 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template

Changeset: 0b3b41d978c4
Author:iris
Date:  2015-10-05 20:56 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0b3b41d978c4

Merge

- 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template

Changeset: 70f3415f2adf
Author:iris
Date:  2015-10-25 19:16 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/70f3415f2adf

Merge

! make/build.xml
- 

hg: jigsaw/jake/hotspot: 29 new changesets

[erik . joelsson]

Changeset: 5b88604f11a1
Author:ihse
Date:  2015-06-12 08:31 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5b88604f11a1

8085822: JEP 223: New Version-String Scheme (initial integration)
Reviewed-by: erikj, dcubed, dholmes, alanb
Contributed-by: Magnus Ihse Bursie , Alejandro E 
Murillo 

! make/Makefile
! make/aix/Makefile
! make/aix/makefiles/buildtree.make
! make/aix/makefiles/defs.make
! make/aix/makefiles/vm.make
! make/bsd/Makefile
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/defs.make
! make/bsd/makefiles/vm.make
! make/defs.make
- make/jdk6_hotspot_distro
! make/jdk_version
! make/linux/Makefile
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/defs.make
! make/linux/makefiles/vm.make
! make/solaris/Makefile
! make/solaris/makefiles/buildtree.make
! make/solaris/makefiles/defs.make
! make/solaris/makefiles/sparcWorks.make
! make/solaris/makefiles/vm.make
! make/windows/build.make
! make/windows/makefiles/compile.make
! make/windows/makefiles/debug.make
! make/windows/makefiles/defs.make
! make/windows/makefiles/fastdebug.make
! make/windows/makefiles/product.make
! make/windows/makefiles/vm.make
! make/windows/projectfiles/common/Makefile
! src/share/vm/prims/jvm.h
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/java.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/runtime/vm_version.hpp
! test/runtime/6981737/Test6981737.java

Changeset: befaf8025423
Author:ihse
Date:  2015-06-12 08:32 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/befaf8025423

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: dc45a1d895ff
Author:amurillo
Date:  2015-06-19 10:34 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dc45a1d895ff

8087202: Add support for PATCH field and remove unused fields of new version 
string
Reviewed-by: dholmes, alanb

! make/Makefile
! make/aix/makefiles/vm.make
! make/bsd/makefiles/vm.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/vm.make
! make/windows/makefiles/defs.make
! make/windows/makefiles/vm.make
! src/share/vm/memory/universe.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvm.h
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/java.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/runtime/vm_version.hpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/management.cpp
! src/share/vm/services/runtimeService.cpp

Changeset: f3653f892046
Author:iris
Date:  2015-06-29 11:27 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f3653f892046

Merge

- make/jdk6_hotspot_distro
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/services/diagnosticCommand.cpp

Changeset: e4479f2e1660
Author:iris
Date:  2015-07-06 11:47 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e4479f2e1660

Merge

- make/jdk6_hotspot_distro
! src/share/vm/runtime/arguments.cpp
! src/share/vm/services/management.cpp

Changeset: 3285a0be012c
Author:iris
Date:  2015-07-13 13:23 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3285a0be012c

Merge

- make/jdk6_hotspot_distro
! src/share/vm/memory/universe.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/runtime/vm_version.hpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/management.cpp

Changeset: 4290c175cba8
Author:iris
Date:  2015-07-20 11:00 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4290c175cba8

Merge

- make/jdk6_hotspot_distro
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 3c4a0de02f61
Author:iris
Date:  2015-07-23 13:19 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3c4a0de02f61

Merge

- make/jdk6_hotspot_distro
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/vm.make
! src/share/vm/memory/universe.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvm.h
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vm_version.cpp

Changeset: b659c1f569b0
Author:iris
Date:  2015-08-03 09:26 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b659c1f569b0

Merge

- make/jdk6_hotspot_distro
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/java.cpp
! src/share/vm/services/diagnosticCommand.cpp

Changeset: 491706ae0c91
Author:iris
Date:  2015-08-10 19:58 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/491706ae0c91

Merge

- make/jdk6_hotspot_distro
! src/share/vm/runtime/arguments.cpp

Changeset: 75a366cb8150
Author:iris
Date:  2015-08-17 13:02 -0700
URL:   

hg: jigsaw/jake/jaxws: 2 new changesets

[erik . joelsson]

Changeset: e625f295b89e
Author:lana
Date:  2015-12-02 15:55 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/e625f295b89e

Added tag jdk-9+95 for changeset 3e03ddaaac65

! .hgtags

Changeset: 895fd3aeee77
Author:erikj
Date:  2015-12-03 11:35 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/895fd3aeee77

Merge

hg: jigsaw/jake/jdk: 36 new changesets

[erik . joelsson]

Changeset: 474db9ef5ee7
Author:ihse
Date:  2015-06-11 00:23 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/474db9ef5ee7

8085822: JEP 223: New Version-String Scheme (initial integration)
Reviewed-by: erikj, dcubed, dholmes, alanb
Contributed-by: Magnus Ihse Bursie , Alejandro E 
Murillo , Kumar Srinivasan 


! make/CompileDemos.gmk
! make/data/mainmanifest/manifest.mf
! make/gensrc/GensrcMisc.gmk
! make/launcher/Launcher-jdk.accessibility.gmk
! make/launcher/Launcher-jdk.pack200.gmk
! make/launcher/LauncherCommon.gmk
! make/lib/CoreLibraries.gmk
! src/java.base/share/classes/sun/misc/Version.java.template
! src/java.base/share/native/include/jvm.h
! src/java.base/share/native/launcher/defines.h
! src/java.base/share/native/launcher/main.c
! src/java.base/share/native/libjava/System.c
! src/java.base/share/native/libjava/Version.c
! src/java.base/share/native/libjava/jdk_util.c
! src/java.base/windows/native/common/version.rc
! src/java.desktop/windows/native/libawt/windows/awt.rc
! src/jdk.accessibility/windows/native/common/AccessBridgeStatusWindow.RC
! test/sun/misc/Version/Version.java

Changeset: d937975320cc
Author:ihse
Date:  2015-06-11 00:51 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d937975320cc

Merge

- src/java.base/share/classes/sun/misc/JavaBeansIntrospectorAccess.java
- src/java.base/share/classes/sun/nio/cs/AbstractCharsetProvider.java
- src/java.base/share/classes/sun/security/ssl/EngineArgs.java
- src/java.base/share/classes/sun/security/ssl/EngineInputRecord.java
- src/java.base/share/classes/sun/security/ssl/EngineOutputRecord.java
- src/java.base/share/classes/sun/security/ssl/EngineWriter.java
- src/java.base/share/classes/sun/security/ssl/KerberosClientKeyExchange.java
- src/java.base/share/classes/sun/security/ssl/Krb5Helper.java
- src/java.base/share/classes/sun/security/ssl/Krb5Proxy.java
- 
src/java.security.jgss/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java
- 
src/java.security.jgss/share/classes/sun/security/ssl/krb5/KerberosPreMasterSecret.java
- src/java.security.jgss/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java
- test/java/lang/Character/UnicodeBlock/NonOptimalMapSize.java

Changeset: 60387e5d6822
Author:amurillo
Date:  2015-06-19 10:58 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/60387e5d6822

8087202: Add support for PATCH field and remove unused fields of new version 
string
Reviewed-by: dholmes, alanb

! make/mapfiles/libjava/mapfile-vers
! src/java.base/share/classes/sun/misc/Version.java.template
! src/java.base/share/native/include/jvm.h
! src/java.base/share/native/libjava/Version.c
! src/java.base/share/native/libjava/jdk_util.c
! test/sun/misc/Version/Version.java

Changeset: 6e98b46d77cc
Author:ksrini
Date:  2015-06-26 15:15 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6e98b46d77cc

8129601: [launcher] test VersionCheck.java fails with new version string
Reviewed-by: alanb

! src/java.base/share/native/launcher/defines.h
! src/java.base/share/native/libjli/java.c
! src/java.base/share/native/libjli/java.h
! test/tools/launcher/VersionCheck.java

Changeset: ae0e82812f1f
Author:iris
Date:  2015-06-29 11:28 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ae0e82812f1f

Merge

! make/mapfiles/libjava/mapfile-vers

Changeset: 18d192a33f98
Author:iris
Date:  2015-07-06 11:49 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/18d192a33f98

Merge

! make/lib/CoreLibraries.gmk

Changeset: 7e6147f7adab
Author:iris
Date:  2015-07-13 13:40 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7e6147f7adab

Merge

! src/java.base/share/native/libjli/java.c
! src/java.desktop/windows/native/libawt/windows/awt.rc

Changeset: 165608bfa113
Author:iris
Date:  2015-07-20 09:40 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/165608bfa113

8130696: Security Providers need to have their version numbers updated for JDK 9
Reviewed-by: ascarpino, mullan, valeriep, weijun, wetmore

! src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java
! src/java.base/share/classes/sun/security/provider/MD4.java
! src/java.base/share/classes/sun/security/provider/Sun.java
! src/java.base/share/classes/sun/security/provider/VerificationProvider.java
! src/java.base/share/classes/sun/security/rsa/SunRsaSign.java
! src/java.base/share/classes/sun/security/ssl/JsseJce.java
! src/java.base/share/classes/sun/security/ssl/SunJSSE.java
! src/java.naming/share/classes/sun/security/provider/certpath/ldap/JdkLDAP.java
! src/java.security.jgss/share/classes/sun/security/jgss/SunProvider.java
! 
src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java
! src/java.security.sasl/share/classes/com/sun/security/sasl/Provider.java
! 

hg: jigsaw/jake: Use VERSION_NUMBER for jmods until jtreg can handle new version string

[alan . bateman]

Changeset: d8851c484f37
Author:alanb
Date:  2015-12-03 16:27 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/d8851c484f37

Use VERSION_NUMBER for jmods until jtreg can handle new version string

! make/CreateJmods.gmk

visibility, readability, accessibility and reflection

[Peter Levart]

Hi,

If there are two modules:

module a {
requires b;
}

with class:

package p;
public class C {
public static void main(String[] args) {
new q.D();
}
}

and:

module b {
exports q;
}

with class:

package q;
public class D {
}


...then for a constructor invocation expression in p.C:

new q.D();

to compile and run, three things must hold (two for compile, three for run):

- module a must read module b
- module b must export package q to at least module a
- class q.D must be visible from class p.C meaning that they must either 
be loaded by the same classloader or the classloader of p.C must 
delegate to the classloader of q.D directly or indirectly


Now lets exchange this constructor invocation expression with equivalent 
reflection code in p.C::main:


Class dClass = Class.forName("q.D");
dClass.newInstance();

To run these two statements the same three things must hold. I would 
expect that individual statements need the following:


Class.forName("q.D");

- module a must read module b
- class q.D must be visible from class p.C meaning that they must either 
be loaded by the same classloader or the classloader of p.C must 
delegate to the classloader of q.D directly or indirectly


dClass.newInstance();

- module b must export package q to at least module a


But in fact, the newInstance invocation also needs:

- module a must read module b


So it seems that readability is checked both times. I would like to know 
what is the reasoning behind that. Since visibility (class loading) must 
be aligned with readability (read edges / requires), I was not expecting 
module system to demand readability where visibility is not required 
(like for example in invocation through reflection). When the 
constructor is invoked via bytecodes:


new q.D();

two things are performed:

- class D is resolved (needs visibility and readability)
- access to D/D. is performed (needs accessibility)

With reflection, I would expect Class.forName() to be the resolving part 
and .newInstance() to just be accessing the class/member.



Regards, Peter

Re: JVMTI and instrumentation

[Michael Rasmussen]

On 3 December 2015 at 16:49, Alan Bateman  wrote:
> Good to hear you got it going and I hope you will be able to try things out
> and work with us as JVM TI evolves to work with module aware agents.

I'm looking forward to it.

> Just so I understand, are you changing the memory in the value returned by
> GetSystemProperty and not calling SetSystemProperty?
No, was using SetSystemProperty.

Quick example code: http://pastebin.com/7BCS1rQu
With the output: http://pastebin.com/3e1SZ1Zj

As seen, the value of jdk.boot.class.path.append is the sun.boot.class.path
from the index that was the original value before I changed it.

/Michael

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

[Rafael Winterhalter]

As I understand it, this is not sufficient.

Assuming A is a serialization library: If the object of C contains an
instance encapsulated by D, then B would need to make sure that it can read
C and D before handing the instance to A. For this it would of course be
necessary to understand the inner workings of A. This is trivial for a
serialization library but in the general case this involves more effort and
is difficult to accomplish without runtime errors.

Is that incorrect?

2015-12-03 20:48 GMT+01:00 Alex Buckley :

> "needs to find all modules potentially involved" ? Module B needs to
> configure readability to solely the module containing the class that A's
> code (well, the code-that-used-to-be-A-but-is-now-part-of-B) wishes to
> access reflectively. Here it is: objFromC.getClass().getModule().
>
> Alex
>
> On 12/3/2015 11:43 AM, Rafael Winterhalter wrote:
>
>> But then library B needs to find all modules potentially involved. With
>> the classical example of a serialization library that traverses a full
>> object graph, this would require B to do the same for anytime an object
>> is handed to the shaded dependency. To me that appears impractical.
>>
>> Am 03.12.2015 8:37 nachm. schrieb "Alex Buckley"
>> >:
>>
>> Yes, A's reflective access to C's classes will fail, due to the
>> action of B's author in grabbing and shading A.
>>
>> Module B is responsible for configuring its (B's) readability to the
>> module containing C's classes (be that a named module if C has been
>> modularized, or the unnamed module if C is still a JAR on the
>> classpath).
>>
>> Module B can achieve this with a single call to
>> j.l.r.Module::addReads.
>>
>> Alex
>>
>> On 12/3/2015 11:19 AM, Rafael Winterhalter wrote:
>>
>> Sorry, I realize that I was not precise.
>>
>> Assuming that pre-module library A is shaded by modularized
>> library B. User
>> code C is then using library B. Internally, library B passes
>> objects to
>> library A that is using reflection on C without being aware of
>> the module
>> boundary. Would this now fail as library A is now part of B's
>> module?
>> Am 03.12.2015 8:10 nachm. schrieb "Alan Bateman"
>> >:
>>
>>
>> On 03/12/2015 18:30, Rafael Winterhalter wrote:
>>
>> As a follow-up question. What if I need to import a
>> library into my
>> namespace and therewith module? ("shaded dependencies")
>> This is a quite
>> common practice to avoid version conflicts.
>>
>> Would for example the reflection semantics for these
>> classes change? Or
>> would the byte code level serve as a fallback? (But then
>> the mentioned
>> "modularity for pre-9 libraries" would not work.)
>>
>> Can you expand the example a bit? I assume the uber JAR
>> has the
>>
>> dependences (in renamed packages) but those packages are not
>> exported. In
>> that case then none of the types in the shaded dependences
>> will be
>> accessible outside of the module. Within the module, which
>> includes the
>> shaded dependences, then all public types are available to
>> code in the
>> module, doesn't matter if the reference is static or core
>> reflection.
>>
>> -Alan
>>
>>

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

[Alan Bateman]

On 03/12/2015 19:43, Rafael Winterhalter wrote:

But then library B needs to find all modules potentially involved. With the
classical example of a serialization library that traverses a full object
graph, this would require B to do the same for anytime an object is handed
to the shaded dependency. To me that appears impractical.


I think I've lost you here or maybe the example has teleported.

As I understand the example then code in A (which is in module B) is 
trying to use core reflection to access some type in consumer module C. 
Assuming the C type is public and in a packaged exported by C to B then 
the code in A should be able to access it, it just needs to use 
jlr.Module::addReads as Alex said. It may be that B already reads C, in 
which case this addReads will be a noop. So no walking objects graph or 
anything complicated in this example.


-Alan.

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

[Alex Buckley]

Yes, A's reflective access to C's classes will fail, due to the action 
of B's author in grabbing and shading A.


Module B is responsible for configuring its (B's) readability to the 
module containing C's classes (be that a named module if C has been 
modularized, or the unnamed module if C is still a JAR on the classpath).


Module B can achieve this with a single call to j.l.r.Module::addReads.

Alex

On 12/3/2015 11:19 AM, Rafael Winterhalter wrote:

Sorry, I realize that I was not precise.

Assuming that pre-module library A is shaded by modularized library B. User
code C is then using library B. Internally, library B passes objects to
library A that is using reflection on C without being aware of the module
boundary. Would this now fail as library A is now part of B's module?
Am 03.12.2015 8:10 nachm. schrieb "Alan Bateman" :



On 03/12/2015 18:30, Rafael Winterhalter wrote:


As a follow-up question. What if I need to import a library into my
namespace and therewith module? ("shaded dependencies") This is a quite
common practice to avoid version conflicts.

Would for example the reflection semantics for these classes change? Or
would the byte code level serve as a fallback? (But then the mentioned
"modularity for pre-9 libraries" would not work.)

Can you expand the example a bit? I assume the uber JAR has the

dependences (in renamed packages) but those packages are not exported. In
that case then none of the types in the shaded dependences will be
accessible outside of the module. Within the module, which includes the
shaded dependences, then all public types are available to code in the
module, doesn't matter if the reference is static or core reflection.

-Alan

RFE support jar as modulepath argument

[Robert Scholte]

Hi,

On behalf of the Apache Maven team I'm working on the Plexus Compiler[1]  
to support compilation of modules and I'm struggling with the  
specification of the modulepath.


According to JEP 261[1] the path of -mp  is not the same as -cp  
. Based of the commandline help of javac I assumed both paths were  
the same, since the parameter argument has the same name.
After reading the specs it seems like I can only refer to a directory  
containing modules. For a dependency specified in the pom.xml I could  
refer to the directory (within the local repository) containing that  
specific artifact.  However, such directory contains more files, so I  
can't be certain the correct file is picked up (e.g.  
cooomons-lang3-3.4[2]. Both commons-lang3-3.4.jar and  
commons-lang3-3.4-tests.jar might contain a module-info.class, but it is  
uncertain if this was the file specified as dependency).
So it seems like for every Maven Project I need to copy the dependencies  
to a specific folder and use this as argument for -mp. My problem with  
this is:
  a. IO is considered slow, so making these copies are expensive. In case  
of a multimodule Maven project this will have a huge negative impact.  
Based on several mailingthreads it seems to me that speed is the most  
important requirement for a build tool.
  b. You will get dozens of copies of the same jar all over your system.  
This reminds me of the times where you added a lib-directory to your java  
project and committed all these files into your SCM...


The beauty of the classpath is that you can *refer* to a specific *jar*.  
It is precise and has no overhead.


Executing javac is probably fast, but the preparations the  
maven-compiler-plugin must do to be able to call javac will take much more  
time.


To ensure that exactly the dependencies as specified in the pom.xml are  
used (not more or less) without the need to copy files it would be my wish  
to have -mp also support (jar)-files.


thanks,
Robert Scholte

[1] https://github.com/codehaus-plexus/plexus-compiler/tree/jigsaw-ea
[2] https://repo1.maven.org/maven2/org/apache/commons/commons-lang3/3.4/

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

[Alan Bateman]

On 03/12/2015 18:30, Rafael Winterhalter wrote:

As a follow-up question. What if I need to import a library into my
namespace and therewith module? ("shaded dependencies") This is a quite
common practice to avoid version conflicts.

Would for example the reflection semantics for these classes change? Or
would the byte code level serve as a fallback? (But then the mentioned
"modularity for pre-9 libraries" would not work.)

Can you expand the example a bit? I assume the uber JAR has the 
dependences (in renamed packages) but those packages are not exported. 
In that case then none of the types in the shaded dependences will be 
accessible outside of the module. Within the module, which includes the 
shaded dependences, then all public types are available to code in the 
module, doesn't matter if the reference is static or core reflection.


-Alan

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

[Rafael Winterhalter]

Sorry, I realize that I was not precise.

Assuming that pre-module library A is shaded by modularized library B. User
code C is then using library B. Internally, library B passes objects to
library A that is using reflection on C without being aware of the module
boundary. Would this now fail as library A is now part of B's module?
Am 03.12.2015 8:10 nachm. schrieb "Alan Bateman" :

>
> On 03/12/2015 18:30, Rafael Winterhalter wrote:
>
>> As a follow-up question. What if I need to import a library into my
>> namespace and therewith module? ("shaded dependencies") This is a quite
>> common practice to avoid version conflicts.
>>
>> Would for example the reflection semantics for these classes change? Or
>> would the byte code level serve as a fallback? (But then the mentioned
>> "modularity for pre-9 libraries" would not work.)
>>
>> Can you expand the example a bit? I assume the uber JAR has the
> dependences (in renamed packages) but those packages are not exported. In
> that case then none of the types in the shaded dependences will be
> accessible outside of the module. Within the module, which includes the
> shaded dependences, then all public types are available to code in the
> module, doesn't matter if the reference is static or core reflection.
>
> -Alan
>

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

[Alex Buckley]

On 12/3/2015 10:04 AM, Peter Levart wrote:

Loosely related to this debate, I would like to ask what's the story
with modular jars that can run on JDK8 classpath and as modules on JDK9.
How is one supposed to create such jar file as it must have:

- classes compiled with JDK8 javac (or JDK9 javac with -source 8 -target
8 or -release 8)
- module-info.class which can only be produced with JDK9 javac, but not
with -source 8 -target 8 or -release 8

Is one expected to invoke javac twice, 1st for sources (excluding
module-info.java), 2nd just for module-info.java ?


Yes (or get your build tool to do it).

More generally, anyone creating a multi-release JAR file (you didn't ask 
about them, and they are not necessary to achieve what you want above, 
but I mention them for completeness) will invoke javac multiple times. 
It's the cost of doing business.



Wouldn't it be nice
for jar tool to be able to fabricate the module-info.class from scratch
using just command-line options?


No. How does a Java compiler know what's exported from a module, in 
order to enforce accessibility, if the module declaration isn't 
fabricated until packaging time?


I expect you will say, "Encode exports somewhere other than the module 
declaration, such as with @Exported annotations on types or packages." 
To which I repeat: "if we're going to introduce the concept of a
module to millions of Java developers, we see value in consolidating 
both kinds of configuration [dependencies and exports] in one place".


Alex

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

[Rafael Winterhalter]

But then library B needs to find all modules potentially involved. With the
classical example of a serialization library that traverses a full object
graph, this would require B to do the same for anytime an object is handed
to the shaded dependency. To me that appears impractical.
Am 03.12.2015 8:37 nachm. schrieb "Alex Buckley" :

> Yes, A's reflective access to C's classes will fail, due to the action of
> B's author in grabbing and shading A.
>
> Module B is responsible for configuring its (B's) readability to the
> module containing C's classes (be that a named module if C has been
> modularized, or the unnamed module if C is still a JAR on the classpath).
>
> Module B can achieve this with a single call to j.l.r.Module::addReads.
>
> Alex
>
> On 12/3/2015 11:19 AM, Rafael Winterhalter wrote:
>
>> Sorry, I realize that I was not precise.
>>
>> Assuming that pre-module library A is shaded by modularized library B.
>> User
>> code C is then using library B. Internally, library B passes objects to
>> library A that is using reflection on C without being aware of the module
>> boundary. Would this now fail as library A is now part of B's module?
>> Am 03.12.2015 8:10 nachm. schrieb "Alan Bateman" > >:
>>
>>
>>> On 03/12/2015 18:30, Rafael Winterhalter wrote:
>>>
>>> As a follow-up question. What if I need to import a library into my
 namespace and therewith module? ("shaded dependencies") This is a quite
 common practice to avoid version conflicts.

 Would for example the reflection semantics for these classes change? Or
 would the byte code level serve as a fallback? (But then the mentioned
 "modularity for pre-9 libraries" would not work.)

 Can you expand the example a bit? I assume the uber JAR has the

>>> dependences (in renamed packages) but those packages are not exported. In
>>> that case then none of the types in the shaded dependences will be
>>> accessible outside of the module. Within the module, which includes the
>>> shaded dependences, then all public types are available to code in the
>>> module, doesn't matter if the reference is static or core reflection.
>>>
>>> -Alan
>>>
>>>

Re: visibility, readability, accessibility and reflection

[Alex Buckley]

On 12/3/2015 11:04 AM, Peter Levart wrote:

On 12/03/2015 07:14 PM, Alan Bateman wrote:

On 03/12/2015 17:12, Peter Levart wrote:

Now lets exchange this constructor invocation expression with
equivalent reflection code in p.C::main:

Class dClass = Class.forName("q.D");
dClass.newInstance();

To run these two statements the same three things must hold. I would
expect that individual statements need the following:

Class.forName("q.D");

- module a must read module b

There isn't an access check here so no checking that a reads b. There
may of course be reasons why D might not be able to link to its
supertype and other issues but I assume they aren't interesting here.


Ah, I see. When there's no "requires b" in module a, then b is not
included in the configuration if I just do "java -m a/p.C", so that's
the problem of visibility because of missing module. When I also
"-addmods b", then Class.forName("q.D") works and I only get
IllegalAccessException in .newInstance()




- class q.D must be visible from class p.C meaning that they must
either be loaded by the same classloader or the classloader of p.C
must delegate to the classloader of q.D directly or indirectly

dClass.newInstance();

- module b must export package q to at least module a


But in fact, the newInstance invocation also needs:

- module a must read module b


So it seems that readability is checked both times. I would like to
know what is the reasoning behind that.

Class.forName doesn't do access checks so hopefully that makes things
clearer.


Ok, very clear now. So: readability + exportability + class/member
access modifiers == accessibility


Yes. This was explicitly stated in the first section of "Project Jigsaw: 
Under The Hood" -- accessibility is a two way street: module a reads 
module b, module b exports package q to at least module a.



But anyway. I'm trying to understand why a model where readability would
be a requirement for visibility and so accessibility could be reduced
to  exportability + class/member access modifiers is not a viable
alternative? Would that require Class loading changes? It would not be
possible to enforce this inside the class-loader, right?


This is an insightful question. Nothing is impossible, but it would 
require such deep changes to the JVM's class loading mechanism that it 
would make make the changes we've made to the JVM's access control 
mechanism look like child's play. (By "JVM", I mean the abstract JVM 
described in the JVM Spec, not any particular implementation such as 
HotSpot.)


Alex

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

[Alex Buckley]

On 12/3/2015 2:04 PM, Peter Levart wrote:

On 12/03/2015 08:46 PM, Alex Buckley wrote:

On 12/3/2015 10:04 AM, Peter Levart wrote:

Loosely related to this debate, I would like to ask what's the story
with modular jars that can run on JDK8 classpath and as modules on JDK9.
How is one supposed to create such jar file as it must have:

- classes compiled with JDK8 javac (or JDK9 javac with -source 8 -target
8 or -release 8)
- module-info.class which can only be produced with JDK9 javac, but not
with -source 8 -target 8 or -release 8

Is one expected to invoke javac twice, 1st for sources (excluding
module-info.java), 2nd just for module-info.java ?


Yes (or get your build tool to do it).

More generally, anyone creating a multi-release JAR file (you didn't
ask about them, and they are not necessary to achieve what you want
above, but I mention them for completeness) will invoke javac multiple
times. It's the cost of doing business.


Wouldn't it be nice
for jar tool to be able to fabricate the module-info.class from scratch
using just command-line options?


No. How does a Java compiler know what's exported from a module, in
order to enforce accessibility, if the module declaration isn't
fabricated until packaging time?


In this case (of building a modular jar file that is able to run on JDK8
classpath), classes are compiled with javac -release 8, which can't run
in "modular" mode and consequently can't enforce any accessibility. When
module-info.java is then compiled separately, there are no classes to be
compiled and so there's nothing to enforce accessibility on


Sure, this special case of build-for-JDK-8-then-add-modular-info could 
be solved by passing the modular info to the jar tool. But the modular 
info is non-trivial -- a list of module dependencies plus a list of 
exported packages -- so in practice you'd stick the info in an @argfile 
and now you've reinvented module-info.java.


Alex

hg: jigsaw/jake: Use VERSION_SHORT again, now that jtreg has been updated

[jonathan . gibbons]

Changeset: 1c8c3c9e2494
Author:jjg
Date:  2015-12-03 14:01 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/1c8c3c9e2494

Use VERSION_SHORT again, now that jtreg has been updated

! make/CreateJmods.gmk

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

[Alex Buckley]

When the author of B decided to shade A, it became B's responsibility to 
configure the readability needed by A's reflective code.


"But B doesn't know anything about how A works. The shading was only to 
use a different version of A than was observable on the modulepath."


OK, then shading A wasn't the right solution.

One possibility is to continue renaming A's classes, but to put them in 
Aprime.jar on the modulepath. That would generate an automatic module 
Aprime which B could require. The Aprime module reads everything, so its 
reflective inspection of C's classes et al will work -- until an object 
of some module-private class is reached.


So, I've solved your multiple-versions-of-A problem but I haven't solved 
your encapsulation problem. Again, the tension between strong 
encapsulation and serialization libraries is something I'm sure the 
Expert Group will take up.


Alex

On 12/3/2015 12:43 PM, Rafael Winterhalter wrote:

The point is that A is shaded. It is compiled prior to Java 9 and not aware
of modules or Java 9 APIs. Therefore, it does not add read edges.

B only imports A to avoid conflicts with other versions of A where A
implicitly becomes a part of module B.
Am 03.12.2015 9:37 nachm. schrieb "Alan Bateman" :


On 03/12/2015 19:58, Rafael Winterhalter wrote:


:

Assuming A is a serialization library: If the object of C contains an
instance encapsulated by D, then B would need to make sure that it can
read
C and D before handing the instance to A. For this it would of course be
necessary to understand the inner workings of A. This is trivial for a
serialization library but in the general case this involves more effort
and
is difficult to accomplish without runtime errors.

Is that incorrect?

The B code doesn't need to do anything special here, it just passes

references to A code (in the same module). If the A code is doing
serialization then it's walking object graphs and might have to add some
transient read edges (via jlr.Module::addReads) as it goes. If the walk
leads to it trying to access types that aren't public or aren't in packages
exported to module B then it will get an IllegalAccessException, that is to
be expected. So I don't think there is any specific to shading or uber JARs
in this example.

-Alan.

Re: A way to opt out of access restrictions on non-exported members.

[mark . reinhold]

2015/12/1 3:29 -0800, javali...@cbfiddle.com:
>> On Dec 1, 2015, at 2:13 PM, mark.reinh...@oracle.com wrote:
>> Yes.  The users of your library are, knowingly or (usually) not, in an
>> inherently dangerous position.  Their own libraries or applications now
>> depend upon undocumented and unsupported internals of the JDK, which are
>> subject to change at any time and for any reason.  If they have to use
>> a command-line flag to enable such hacks then they are more likely to
>> recognize the danger, so they can judge the risk and plan accordingly.
> 
> That sounds good in theory, but in practice it may be judged an
> annoyance with little or no actual benefit.
> 
> In the case of a workaround, what is likely to happen if the JDK
> changes in an incompatible way is that the workaround fails, leaving
> the application in the same situation it would be without the
> workaround, i.e. with buggy behavior.
> 
> Also, there are plenty of ways that code can depend on JDK
> implementation details without using private APIs, and there is no
> protection from that.

Well sure, but that's not a reason to not provide protection from other
kinds of implementation details when that's possible.

> I think your comment about JDK internals being subject to change at
> any time is overstated. The application developer will only be
> affected when they upgrade to a new JDK version, not at random times,
> and upgrading to a new JDK version merits extensive retesting.

Yet one of the reasons that it merits extensive retesting is precisely
because so many libraries depend upon JDK-internal APIs.

>> I do think it's worth exploring alternative ways to break encapsulation
>> which are more compact, more narrowly scoped, and yet give modules that
>> really need to do that some additional flexibility.  One idea we've
>> considered is a command-line option to grant a module the power to break
>> whatever encapsulation boundaries it needs to, via the API.  That way a
>> user would just need to grant your module this power on the command line
>> rather than be concerned in any way with the specific modules/packages
>> your code needs to break into, and also you, over time, can update your
>> library to change or minimize the amount of encapsulation that it
>> breaks.
> 
> I would be happier with a solution that documents specific
> penetrations of encapsulation in a way that can be interrogated by a
> tool. Then application developers can choose whether to run the tool,
> rather than getting random run time access errors or buggy behavior
> when the penetration is rejected.

Something like that might work for simple static references to internal
APIs, such as your workaround scenario.  It's infeasible, however, for
other use cases in which encapsulation must be broken in a more dynamic
fashion, e.g., frameworks that use reflection to inspect the internals
of classes in modules not known when the framework is compiled.

- Mark

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

[Rafael Winterhalter]

Given that B, a public library that is not aware of C (and does therefore
not read C) wants to access that module's class via reflection, it needs to
add a read edge to C as discussed.

If an object of C references an object of D that is returned by reflection
on objects of C, the same holds for this other module.

If it is not B but the shaded A that uses reflection, then B needs to add C
and D before passing the object to A.

Is that incorrect?
Am 03.12.2015 9:24 nachm. schrieb "Alan Bateman" :

>
>
> On 03/12/2015 19:43, Rafael Winterhalter wrote:
>
>> But then library B needs to find all modules potentially involved. With
>> the
>> classical example of a serialization library that traverses a full object
>> graph, this would require B to do the same for anytime an object is handed
>> to the shaded dependency. To me that appears impractical.
>>
>> I think I've lost you here or maybe the example has teleported.
>
> As I understand the example then code in A (which is in module B) is
> trying to use core reflection to access some type in consumer module C.
> Assuming the C type is public and in a packaged exported by C to B then the
> code in A should be able to access it, it just needs to use
> jlr.Module::addReads as Alex said. It may be that B already reads C, in
> which case this addReads will be a noop. So no walking objects graph or
> anything complicated in this example.
>
> -Alan.
>

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

[Alex Buckley]

"needs to find all modules potentially involved" ? Module B needs to 
configure readability to solely the module containing the class that A's 
code (well, the code-that-used-to-be-A-but-is-now-part-of-B) wishes to 
access reflectively. Here it is: objFromC.getClass().getModule().


Alex

On 12/3/2015 11:43 AM, Rafael Winterhalter wrote:

But then library B needs to find all modules potentially involved. With
the classical example of a serialization library that traverses a full
object graph, this would require B to do the same for anytime an object
is handed to the shaded dependency. To me that appears impractical.

Am 03.12.2015 8:37 nachm. schrieb "Alex Buckley"
>:

Yes, A's reflective access to C's classes will fail, due to the
action of B's author in grabbing and shading A.

Module B is responsible for configuring its (B's) readability to the
module containing C's classes (be that a named module if C has been
modularized, or the unnamed module if C is still a JAR on the
classpath).

Module B can achieve this with a single call to j.l.r.Module::addReads.

Alex

On 12/3/2015 11:19 AM, Rafael Winterhalter wrote:

Sorry, I realize that I was not precise.

Assuming that pre-module library A is shaded by modularized
library B. User
code C is then using library B. Internally, library B passes
objects to
library A that is using reflection on C without being aware of
the module
boundary. Would this now fail as library A is now part of B's
module?
Am 03.12.2015 8:10 nachm. schrieb "Alan Bateman"
>:


On 03/12/2015 18:30, Rafael Winterhalter wrote:

As a follow-up question. What if I need to import a
library into my
namespace and therewith module? ("shaded dependencies")
This is a quite
common practice to avoid version conflicts.

Would for example the reflection semantics for these
classes change? Or
would the byte code level serve as a fallback? (But then
the mentioned
"modularity for pre-9 libraries" would not work.)

Can you expand the example a bit? I assume the uber JAR
has the

dependences (in renamed packages) but those packages are not
exported. In
that case then none of the types in the shaded dependences
will be
accessible outside of the module. Within the module, which
includes the
shaded dependences, then all public types are available to
code in the
module, doesn't matter if the reference is static or core
reflection.

-Alan

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

[Alex Buckley]

You've presented a new fact about A.

Yes, if A is going to dereference the object graph starting from the 
object created by C's code (presumably as an instance of one of C's 
classes) and passed to B's code, then B would need to read all the 
modules containing the classes of objects in the object graph.


And all those modules need to export the classes' packages to B as well.

And no, B's code cannot configure those other modules to export packages 
to it. This is a point of real tension between strong encapsulation and 
serialization libraries which I'm sure the Expert Group will take up.


Alex

On 12/3/2015 11:58 AM, Rafael Winterhalter wrote:

As I understand it, this is not sufficient.

Assuming A is a serialization library: If the object of C contains an
instance encapsulated by D, then B would need to make sure that it can
read C and D before handing the instance to A. For this it would of
course be necessary to understand the inner workings of A. This is
trivial for a serialization library but in the general case this
involves more effort and is difficult to accomplish without runtime errors.

Is that incorrect?

2015-12-03 20:48 GMT+01:00 Alex Buckley >:

"needs to find all modules potentially involved" ? Module B needs to
configure readability to solely the module containing the class that
A's code (well, the code-that-used-to-be-A-but-is-now-part-of-B)
wishes to access reflectively. Here it is:
objFromC.getClass().getModule().

Alex

On 12/3/2015 11:43 AM, Rafael Winterhalter wrote:

But then library B needs to find all modules potentially
involved. With
the classical example of a serialization library that traverses
a full
object graph, this would require B to do the same for anytime an
object
is handed to the shaded dependency. To me that appears impractical.

Am 03.12.2015 8:37 nachm. schrieb "Alex Buckley"

>>:

 Yes, A's reflective access to C's classes will fail, due to the
 action of B's author in grabbing and shading A.

 Module B is responsible for configuring its (B's)
readability to the
 module containing C's classes (be that a named module if C
has been
 modularized, or the unnamed module if C is still a JAR on the
 classpath).

 Module B can achieve this with a single call to
j.l.r.Module::addReads.

 Alex

 On 12/3/2015 11:19 AM, Rafael Winterhalter wrote:

 Sorry, I realize that I was not precise.

 Assuming that pre-module library A is shaded by modularized
 library B. User
 code C is then using library B. Internally, library B
passes
 objects to
 library A that is using reflection on C without being
aware of
 the module
 boundary. Would this now fail as library A is now part
of B's
 module?
 Am 03.12.2015 8:10 nachm. schrieb "Alan Bateman"
  >>:


 On 03/12/2015 18:30, Rafael Winterhalter wrote:

 As a follow-up question. What if I need to import a
 library into my
 namespace and therewith module? ("shaded
dependencies")
 This is a quite
 common practice to avoid version conflicts.

 Would for example the reflection semantics for
these
 classes change? Or
 would the byte code level serve as a fallback?
(But then
 the mentioned
 "modularity for pre-9 libraries" would not work.)

 Can you expand the example a bit? I assume the
uber JAR
 has the

 dependences (in renamed packages) but those
packages are not
 exported. In
 that case then none of the types in the shaded
dependences
 will be
 accessible outside of the module. Within the
module, which
 includes the
 shaded dependences, then all public types are
available to
 code in the
 module, doesn't matter if the reference is static
or core
 reflection.

 -Alan

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

[Paul Benedict]

On Thu, Dec 3, 2015 at 1:46 PM, Alex Buckley 
wrote:

> I expect you will say, "Encode exports somewhere other than the module
> declaration, such as with @Exported annotations on types or packages." To
> which I repeat: "if we're going to introduce the concept of a
> module to millions of Java developers, we see value in consolidating both
> kinds of configuration [dependencies and exports] in one place".
>

Regardless of the class file vs config file debate, I find it interesting
there is no room for annotations in the current solution. All of this is
still configuration anyway. An @Exported/@Retention(RUNTIME) would easily
eliminate all "export" directives from a developer's Java project. It would
also address Jonathan Gibbon's concern about having to syntax check package
names (empty or not). Anyway, if that is really off the table, have you
thought about how many tools are going to try to fill the gap by offering
the Module Descriptor to be auto-generated? I can easily see a
proliferation of custom x.y.z.@Exported per tool so that a project can be
preprocessed for module-info generation.

Cheers,
Paul

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

[Alan Bateman]

On 03/12/2015 19:58, Rafael Winterhalter wrote:

:

Assuming A is a serialization library: If the object of C contains an
instance encapsulated by D, then B would need to make sure that it can read
C and D before handing the instance to A. For this it would of course be
necessary to understand the inner workings of A. This is trivial for a
serialization library but in the general case this involves more effort and
is difficult to accomplish without runtime errors.

Is that incorrect?

The B code doesn't need to do anything special here, it just passes 
references to A code (in the same module). If the A code is doing 
serialization then it's walking object graphs and might have to add some 
transient read edges (via jlr.Module::addReads) as it goes. If the walk 
leads to it trying to access types that aren't public or aren't in 
packages exported to module B then it will get an 
IllegalAccessException, that is to be expected. So I don't think there 
is any specific to shading or uber JARs in this example.


-Alan.

Re: A way to opt out of access restrictions on non-exported members.

[Alan Snyder]

> On Dec 3, 2015, at 2:49 PM, mark.reinh...@oracle.com wrote:
> 
>> I would be happier with a solution that documents specific
>> penetrations of encapsulation in a way that can be interrogated by a
>> tool. Then application developers can choose whether to run the tool,
>> rather than getting random run time access errors or buggy behavior
>> when the penetration is rejected.
> 
> Something like that might work for simple static references to internal
> APIs, such as your workaround scenario.  It's infeasible, however, for
> other use cases in which encapsulation must be broken in a more dynamic
> fashion, e.g., frameworks that use reflection to inspect the internals
> of classes in modules not known when the framework is compiled.

There is no reason to believe that single mechanism will solve all use cases.

However, if having a single mechanism is important, then it sounds like 
removing the restrictions on reflection would be a good choice.

  Alan

IllegalAccessError even when -XaddExports adds ALL-UNNAMED to the reported module/package

[Roel Spilker]

Hi,

I have a problem using -XaddExports in jigsaw build 94. This is the first
build I tried so I don't know if the problem also occurs in earlier
versions.

In Lombok we use unsupported internal APIs (yes at our own risk)

After reading the instructions on http://openjdk.java.net/jeps/261
"Breaking encapsulation" I've added the -XaddExports flag. The exception I
got luckily gave me the module name as well as the package to export.
However I still got the same exception (details below).

Am I doing something wrong (apart from using unsupported internal APIs)? Is
the exception wrong?

Roel



$ java -version
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build
1.9.0-ea-jigsaw-nightly-h403-20151201-b94)
Java HotSpot(TM) 64-Bit Server VM (build
1.9.0-ea-jigsaw-nightly-h403-20151201-b94, mixed mode)




$ javac
-XaddExports:jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED -cp
lombok.jar Test.java


An annotation processor threw an uncaught exception.
Consult the following stack trace for details.
java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor (in
module: Unnamed Module) cannot access class
com.sun.tools.javac.processing.JavacProcessingEnvironment (in module:
jdk.compiler), com.sun.tools.javac.processing is not exported to Unnamed
Module
at lombok.javac.apt.LombokProcessor.init(LombokProcessor.java:84)
at
lombok.core.AnnotationProcessor$JavacDescriptor.want(AnnotationProcessor.java:87)
at
lombok.core.AnnotationProcessor.init(AnnotationProcessor.java:141)
at
lombok.launch.AnnotationProcessorHider$AnnotationProcessor.init(AnnotationProcessor.java:53)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState.(jdk.compiler@9.0
/JavacProcessingEnvironment.java:669)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.next(jdk.compiler@9.0
/JavacProcessingEnvironment.java:766)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(jdk.compiler@9.0
/JavacProcessingEnvironment.java:857)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment.access$2100(jdk.compiler@9.0
/JavacProcessingEnvironment.java:104)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(jdk.compiler@9.0
/JavacProcessingEnvironment.java:1183)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(jdk.compiler@9.0
/JavacProcessingEnvironment.java:1291)
at
com.sun.tools.javac.main.JavaCompiler.processAnnotations(jdk.compiler@9.0
/JavaCompiler.java:1247)
at com.sun.tools.javac.main.JavaCompiler.compile(jdk.compiler@9.0
/JavaCompiler.java:921)
at com.sun.tools.javac.main.Main.compile(jdk.compiler@9.0
/Main.java:261)
at com.sun.tools.javac.main.Main.compile(jdk.compiler@9.0
/Main.java:143)
at com.sun.tools.javac.Main.compile(jdk.compiler@9.0/Main.java:56)
at com.sun.tools.javac.Main.main(jdk.compiler@9.0/Main.java:42)

Re: The rationale for runtime modularization

[mark . reinhold]

2015/12/3 1:36 -0800, Rafael Winterhalter :
> I am writing this after looking into Jigsaw for about two months and after
> running my open-source libraries and several enterprise applications of my
> current employer using the EA builds.

Glad to hear it!

> In the context of these experiences, I wanted to ask for the rationale of
> project Jigsaw to enforce modularization at runtime.

Short answer: Strong encapsulation at run time greatly improves both
security and maintainability.  (Strong encapsulation at compile time
makes it much easier to prepare for strong encapsulation at run time.)

> In the software I have searched, reflection is predominantly used for
> interacting with code that is unknown during compilation. Of course,
> sometimes reflection is used for abstracting code from types but this is
> extremely rare as generic types pretty much cover this need.
> 
> In practice, this implies that any reflective invocation requires an
> explicit module check. This check can be easily forgotten.

The failure in this case should be easy to diagnose, and the remedy
would be to invoke the Module::addReads method.  (If the target module
doesn't export the relevant package then you'll need to arrange for that
too, either via a command-line flag or possibly by some more convenient
means yet to be devised.)

>Furthermore, the
> compiler does not remind of missing edges when migrating software either.
> It seems to me that the assumption for the runtime checks is that
> invocations might accidentally cross module boundaries.

The checks performed by the reflection APIs themselves are intended to
match those performed by the compiler and the VM for non-reflective
operations, so whether accidental or not a reflective attempt to break
encapsulation will be caught.

> From the code that
> I looked at, I argue that this is already the primary intention when using
> reflection.

Yes, it's probably more common to use reflection to access types in
other modules rather than in the same module.

> One might argue that the same holds for reflection on non-public types.
> However, in this case I believe that security concerns are the main reason
> for enforcing accessability where access can be denied by a security
> manager.

That concern also applies to public types which are not meant to be used
in unintended ways -- and there are lots of those, both in the JDK and
in general.

>  Modules on the other hand cannot provide additional security as
> there is always an opt-out for non-modularized code to avoid such barriers.

Non-modularized code can only break through module barriers if explicit
permission is given for that, on the command line.  So yes, there's an
opt-out mechanism, but it forces the end user to be aware that the
system as a whole will run with compromised integrity.

> I am sure this possibility was considered and I wonder why it was not
> implemented. Looking at the very little practical relevance of heap
> pollution caused by type-erasure, I believe that compile-time
> modularization would work well in this case, too. The Java compiler could
> enforce module boundaries while users of reflection would not be bothered
> with the boundaries they intended to cross in the first place. As the most
> important benefit, migration would be much easier. Libraries could add
> module descriptors to pre-Java-9 bundles without needing to alter code
> since runtime behavior does not longer depend on the bundling format.

If strong encapsulation is to mean anything then it must be enforced at
run time, so a purely compile-time approach is just not viable.  (One
could argue that we already have compile-time modularization today, with
build tools such as Maven, in which case if compile-time modularization
were sufficient then we never would've started this project.)

It's become clear from all the recent feedback that the current design
might be making life a bit too hard for framework libraries that make
heavy use of reflection, so as I indicated in a nearby thread we're
definitely going to look into ways to address that.

- Mark

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

[Alex Buckley]

On 12/3/2015 4:47 AM, David M. Lloyd wrote:

On 12/02/2015 04:49 PM, Alex Buckley wrote:

Now we reach the disagreement. We don't think the module declaration
will be as fluid as you do. Yes, frameworks and other tools will want to
modify module declarations (usually by addition of dependencies or
exports) but that's a handful of actors, all of whom are perfectly
capable of using ASM. 99.99% of humans have no business modifying
someone else's module declaration by hand, so there is no reason for it
to be easy.


I am baffled as to the basis for this assertion.  This kind of change in
fact happens (present tense) frequently - very frequently if you have
any kind of system for updates.  Modules get split or merged,
implementations from one vendor get swapped out for another, multiple
versions of things are introduced.  I honestly can say that I do not
understand how the Jigsaw team arrives at this kind of conclusion with
literally zero production experience!


If you're splitting or merging modules -- especially someone else's! -- 
then you need to let the compiler check that the newly factored modules 
are well-formed: they export packages that they actually contain, and 
they don't read anything that would lead to a split package. (The 
constraints in j.l.m.Configuration::resolve, basically.)


Similarly, if you're changing a module to require a module by Vendor X 
rather than Vendor Y, then you'll want the compiler to check that your 
module isn't led by Vendor X's module to read anything that would lead 
to a split package.


Better to modify module-info.java and recompile it and catch these 
issues up front, than modify MANIFEST.MF and run the main module and 
hope the tests catch them.


Alex

Re: IllegalAccessError even when -XaddExports adds ALL-UNNAMED to the reported module/package

[Jonathan Gibbons]

Roel,

To understand the problem, you need to understand something of how javac 
works.


javac is a Java program, and as such it is composed of a set of modules 
that run in a JVM. The primary module is jdk.compiler, and if you follow 
the dependencies, you'll see it references java.compiler, and of course 
java.base.   Call that the "execution environment".


Now, the function of javac is to analyze and compile source code, which 
exists in a conceptually separate collection of modules. It will 
typically be uncommon for the compiled code to depend on javac's 
modules, like jdk.compiler and java.compiler, and will likely depend on 
its own modules, specified on the module path provided to javac.  All 
modules depend on java.base, but there is no requirement or assumption 
that the version of the java.base module being referenced by the code 
being compiled is the same version of java.base being used by javac code 
itself.  Wind the clock forward a few years, and imagine running javac 
on JDK 10, compiling code to run on JDK 9. Just as on JDK 8, we 
recommend setting the bootclasspath when compiling code for earlier 
versions of JDK, in future, we will recommend that you specify the set 
of system modules appropriate to your setting of -target.  All of which 
is to say that the set of modules used by javac to analyze and compile 
your program is conceptually distinct from the set of modules being used 
to execute javac itself.  Call this new set of modules the "compilation 
environment".


Now consider javac options like -modulepath, -modulesource path and so 
on. These affect the compilation environment. So too does the javac 
-XaddExports option.   When you specify -modulepath to javac, you are 
making additional modules available for use by the code being compiled. 
When you specify -XaddExports to javac, you are instructing javac to 
make some specific packages visible to code in other modules that would 
not otherwise be able to do so.  Neither of these options affect the 
configuration of modules in the JVM being used to execute javac itself.  
The same is true for all other module-related options for javac.


Now consider an annotation processor. Annotation processors are like 
plugins or extensions to javac. As such, they run in the same JVM as 
javac, and more specifically, in the same execution environment as 
javac. (Not 100% true, but close enough for now.)  So, using "javac 
-XaddExports" will not have any direct effect on an annotation 
processor, because javac -XaddExports affects the compilation 
environment available to the annotation processor, not the execution 
environment in which it will be running.


So how do you affect the execution environment used to execute javac and 
any annotation processors that you specify?


You need to pass -XaddExports not to javac but to the underlying 
runtime. The standard practice for all JDK tools invoked from the 
command line is (and has long been) that options prefixed with -J are 
passed to the underlying runtime.  And so, in this case, if you are 
running javac from the command line, you need a command like


$ javac -J-XaddExports:jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED 
-cp lombok.jar Test.java


Here's a different way of looking at it.   javac is "just" a Java 
program, and so running "javac args" is equivalent to executing the 
following command:


$ java   ...some.options...  com.sun.tools.javac.Main  args

So when you specify "javac -XaddExports" the effective command is

$ java   ...some.options...  com.sun.tools.javac.Main -XaddExports...  args

But if you want to affect javac's execution environment, the command you 
really want is


$ java   ...some.options... -XaddExports... com.sun.tools.javac.Main args

i.e. you want -XaddExports passed to the java command, not to the javac 
command.  That is what "javac -J-XaddExports..." does.



-- Jon





On 12/03/2015 03:26 PM, Roel Spilker wrote:

Hi,

I have a problem using -XaddExports in jigsaw build 94. This is the first
build I tried so I don't know if the problem also occurs in earlier
versions.

In Lombok we use unsupported internal APIs (yes at our own risk)

After reading the instructions on http://openjdk.java.net/jeps/261
"Breaking encapsulation" I've added the -XaddExports flag. The exception I
got luckily gave me the module name as well as the package to export.
However I still got the same exception (details below).

Am I doing something wrong (apart from using unsupported internal APIs)? Is
the exception wrong?

Roel



$ java -version
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build
1.9.0-ea-jigsaw-nightly-h403-20151201-b94)
Java HotSpot(TM) 64-Bit Server VM (build
1.9.0-ea-jigsaw-nightly-h403-20151201-b94, mixed mode)




$ javac
-XaddExports:jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED -cp
lombok.jar Test.java


An annotation processor threw an uncaught exception.
Consult the following stack trace for details.