date:20150911

Changeset: 2e667d1f8d67
Author:mchung
Date:  2015-09-11 22:58 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2e667d1f8d67

Adds tests to ProblemList.jake.txt for further investigation

! test/ProblemList.jake.txt

Re: jigsaw vs. jsr166 CVS



On 12/09/2015 00:30, Martin Buchholz wrote:

I tried adding -Xoverride, but it didn't help.

You'll need to use javac -Xmodule:java.base to compile the classes, then 
use -Xoverride at run-time. As it happens, there is an example that 
compiles and uses an development version of CHM here:


  http://openjdk.java.net/projects/jigsaw/quick-start#xoverride

Hopefully it won't too much to get the build.xml to do this.

-Alan

Re: jdeps and annotations parameters


On 9/10/2015 4:23 PM, Jonathan Gibbons wrote:

On 09/08/2015 06:12 PM, Alex Buckley wrote:

I confirm (JDK 8u40) that in an instance/static initializer, where a
local variable declaration includes an annotated type, there is no
RuntimeVisibleTypeAnnotations attribute emitted for the type
annotation! This is so even when the correct meta-annotations appear
on the declaration of the annotation type:

  @Target(ElementType.TYPE_USE)
  @Retention(RetentionPolicy.RUNTIME)

In a ctor, the same local variable declaration does cause a
RuntimeVisibleTypeAnnotations attribute to be emitted for the type
annotation.

I assume the difference stems from the fact that an annotation on a
local variable declaration (the declaration, not its type) was
traditionally never emitted into the class file, regardless of
@Target. In SE 8, an annotation on the type of a local variable
declaration can be emitted into the class file, but presumably some
old code in javac is special-casing initializers and wasn't updated to
understand type annotations therein.

Jon,

Can you confirm my presumption?


I could believe there is a bug in this area, if that is what you are
asking.


javac bug filed as JDK-8136419.

Alex

hg: jigsaw/jake/nashorn: 15 new changesets

Changeset: cffb8ad5ad94
Author:sundar
Date:  2015-08-31 17:51 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/cffb8ad5ad94

8134731: Function.prototype.apply interacts incorrectly with arguments
Reviewed-by: attila, hannesw

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ApplySpecialization.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/FunctionNode.java
+ test/script/basic/JDK-8134731.js

Changeset: eea9202e8930
Author:attila
Date:  2015-08-31 15:18 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/eea9202e8930

8133300: Ensure symbol table immutability in Nashorn AST
Reviewed-by: hannesw, lagergren

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java
- 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AstSerializer.java
+ 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CacheAst.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Compiler.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FindScopeDepths.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Label.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/Block.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/ForNode.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/FunctionNode.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/SwitchNode.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/Symbol.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/TryNode.java
+ 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/AstSerializer.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunction.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java

Changeset: 6e41fdc6acdf
Author:sundar
Date:  2015-09-01 18:28 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/6e41fdc6acdf

8068901: Surprising behavior with more than one functional interface on a class
8068903: Can't invoke vararg @FunctionalInterface methods
Reviewed-by: attila, hannesw

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java
+ test/script/basic/JDK-8068901.js
+ test/script/basic/JDK-8068901.js.EXPECTED
+ test/script/basic/JDK-8068903.js
+ test/src/jdk/nashorn/test/models/VarArgConsumer.java

Changeset: d7d4c84bd750
Author:aw
Date:  2015-09-01 18:19 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/d7d4c84bd750

8134865: Need to restore for container block from lexical context in finally
Reviewed-by: attila, mhaupt

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java
+ test/script/basic/JDK-8134865.js

Changeset: 6b33d7229631
Author:sundar
Date:  2015-09-01 23:08 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/6b33d7229631

8134887: nashorn ant test configuration should disable assertion for 
LamdaFormEditor class
Reviewed-by: attila, jlaskey

! make/project.properties

Changeset: 740fc9e0561f
Author:attila
Date:  2015-09-02 12:26 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/740fc9e0561f

8134930: Defer stack trace walking of NashornException for extracting line 
number and file name
Reviewed-by: hannesw, sundar

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/NashornException.java

Changeset: c31e42c1665f
Author:sundar
Date:  2015-09-02 17:16 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c31e42c1665f

8134931: jdk.nashorn.internal.codegen.TypeMap should not use Map
Reviewed-by: attila, mhaupt

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/TypeMap.java

Changeset: 94302631afc4
Author:attila
Date:  2015-09-02 16:35 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/94302631afc4

8134939: Improve toString method of Dynalink DynamicMethod objects
Reviewed-by: hannesw, sundar

! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SimpleDynamicMethod.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java
! test/script/basic/JDK-8043232.js.EXPECTED
! test/script/basic/JDK-8049242.js.EXPECTED
! test/script/basic/JDK-8079470.js.EXPECTED
+ test/script/basic/JDK-8134939.js
! test/scr

hg: jigsaw/jake/langtools: 5 new changesets

Changeset: 891db670a8cb
Author:mcimadamore
Date:  2015-08-31 15:50 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/891db670a8cb

8134007: Improve string folding
Summary: Generalize string folding algorithm to detect mulitple groups of 
foldable constants within an concat expression
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/parser/8134007/T8134007.java

Changeset: 176472b94f2e
Author:mcimadamore
Date:  2015-08-31 17:33 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/176472b94f2e

8129962: Investigate performance improvements in langtools combo tests
Summary: New combo API that runs all combo instances in a shared javac context 
(whenever possible).
Reviewed-by: jjg, jlahoda, vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/api/MultiTaskListener.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Scope.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Context.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
! test/tools/javac/Diagnostics/6769027/T6769027.java
! test/tools/javac/T7093325.java
- test/tools/javac/TestBootstrapMethodsCount.java
! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java
! test/tools/javac/defaultMethods/static/hiding/InterfaceMethodHidingTest.java
! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java
! test/tools/javac/failover/CheckAttributedTree.java
! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java
! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java
! test/tools/javac/lambda/FunctionalInterfaceConversionTest.java
! test/tools/javac/lambda/LambdaParserTest.java
! test/tools/javac/lambda/MethodReferenceParserTest.java
+ test/tools/javac/lambda/TestBootstrapMethodsCount.java
! test/tools/javac/lambda/TestInvokeDynamic.java
! test/tools/javac/lambda/TestLambdaToMethodStats.java
! test/tools/javac/lambda/bytecode/TestLambdaBytecode.java
! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java
! test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java
- test/tools/javac/lib/JavacTestingAbstractThreadedTest.java
+ test/tools/javac/lib/combo/ComboInstance.java
+ test/tools/javac/lib/combo/ComboParameter.java
+ test/tools/javac/lib/combo/ComboTask.java
+ test/tools/javac/lib/combo/ComboTestHelper.java
+ test/tools/javac/lib/combo/ReusableContext.java
! test/tools/javac/multicatch/7030606/DisjunctiveTypeWellFormednessTest.java
! test/tools/javac/resolve/BitWiseOperators.java
! test/tools/javac/types/ScopeListenerTest.java
! test/tools/javac/varargs/7042566/T7042566.java
! test/tools/javac/varargs/warning/Warn4.java
! test/tools/javac/varargs/warning/Warn5.java

Changeset: ead8b7192f00
Author:lana
Date:  2015-09-03 16:13 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ead8b7192f00

Merge

- test/tools/javac/TestBootstrapMethodsCount.java
- test/tools/javac/lib/JavacTestingAbstractThreadedTest.java

Changeset: a7bc0d2f60ba
Author:lana
Date:  2015-09-11 10:26 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a7bc0d2f60ba

Added tag jdk9-b81 for changeset ead8b7192f00

! .hgtags

Changeset: 96c87be307e1
Author:mchung
Date:  2015-09-11 17:09 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/96c87be307e1

Merge

! .hgtags
! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
- src/jdk.compiler/share/classes/com/sun/tools/javac/sym/CreateSymbols.java
- src/jdk.compiler/share/classes/com/sun/tools/javac/sym/Profiles.java
- 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractProfileIndexWriter.java
- 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java
- 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java
- 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java
- 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java
- 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java
- 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfilePackageSummaryWriter.java
- 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfileSummaryWriter.java
- 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/t

hg: jigsaw/jake/jdk: 24 new changesets

Changeset: 2b3b9aa80615
Author:erikj
Date:  2015-08-28 10:13 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2b3b9aa80615

8134408: Disable warnings for jdk libraries triggered by SS12u4
Reviewed-by: tbell, ihse

! make/lib/Awt2dLibraries.gmk
! make/lib/CoreLibraries.gmk
! make/lib/NetworkingLibraries.gmk

Changeset: 97c5c87e429f
Author:darcy
Date:  2015-08-28 07:55 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/97c5c87e429f

8134678: Problem list SecurityManager/CheckPackageAccess.java
Reviewed-by: lancea

! test/ProblemList.txt

Changeset: 92bea53c71cd
Author:bpb
Date:  2015-08-28 10:46 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/92bea53c71cd

8133987: (fs) Rename GnomeFileTypeDetector to GioFileTypeDetector
Summary: Rename class and associated native file as indicated and fix some 
related comments in the source and test.
Reviewed-by: alanb

! make/lib/NioLibraries.gmk
! make/mapfiles/libnio/mapfile-linux
! make/mapfiles/libnio/mapfile-solaris
! src/java.base/linux/classes/sun/nio/fs/LinuxFileSystemProvider.java
! src/java.base/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java
+ src/java.base/unix/classes/sun/nio/fs/GioFileTypeDetector.java
- src/java.base/unix/classes/sun/nio/fs/GnomeFileTypeDetector.java
+ src/java.base/unix/native/libnio/fs/GioFileTypeDetector.c
- src/java.base/unix/native/libnio/fs/GnomeFileTypeDetector.c
! test/java/nio/file/Files/probeContentType/ParallelProbes.java

Changeset: 0b2d0cf231c7
Author:rhalade
Date:  2015-08-28 13:35 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0b2d0cf231c7

8048601: Tests for JCE crypto ciphers (part 1)
Reviewed-by: valeriep

+ test/com/sun/crypto/provider/Cipher/Blowfish/TestCipherBlowfish.java
+ test/com/sun/crypto/provider/Cipher/DES/TestCipherDES.java
+ test/com/sun/crypto/provider/Cipher/DES/TestCipherDESede.java
+ test/com/sun/crypto/provider/Cipher/PBE/TestCipherPBE.java
+ test/com/sun/crypto/provider/Cipher/TestCipher.java
+ test/com/sun/crypto/provider/Cipher/TextLength/DESCipherWrapper.java
+ test/com/sun/crypto/provider/Cipher/TextLength/PBECipherWrapper.java
+ test/com/sun/crypto/provider/Cipher/TextLength/TestCipherTextLength.java

Changeset: cb39fd2ecf8a
Author:sla
Date:  2015-08-28 13:40 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cb39fd2ecf8a

8134686: Exclude sun/tools/jps/ tests
Reviewed-by: darcy

! test/ProblemList.txt
! test/TEST.ROOT

Changeset: 33cdc422c199
Author:vinnie
Date:  2015-08-31 10:14 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/33cdc422c199

8130800: KeyStore.getInstance(File,char[]) does not throw IOE for null password
Reviewed-by: weijun, mullan

! src/java.base/share/classes/java/security/KeyStore.java

Changeset: 9218a70ee1c6
Author:sla
Date:  2015-08-11 20:38 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9218a70ee1c6

8133314: Update launcher.properties to remove reference to hprof
Reviewed-by: dholmes, sspitsyn, mchung

! src/java.base/share/classes/sun/launcher/resources/launcher.properties

Changeset: e4f2a670470b
Author:jbachorik
Date:  2015-04-09 12:29 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e4f2a670470b

8041565: JMX ObjectName could be refactored to save memory
Reviewed-by: emcmanus, dfuchs, olagneau, smarks

! src/java.management/share/classes/javax/management/ObjectName.java
+ test/javax/management/ObjectName/CompressedStorageTest.java

Changeset: 65c158a0de8c
Author:dsamersoff
Date:  2015-08-17 12:45 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/65c158a0de8c

Merge


Changeset: d49f4e34e260
Author:dbuck
Date:  2015-08-18 04:29 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d49f4e34e260

8133666: OperatingSystemMXBean reports abnormally high machine CPU consumption 
on Linux
Reviewed-by: sla, mgronlun

! src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c

Changeset: 6940407d544a
Author:amurillo
Date:  2015-08-20 07:36 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6940407d544a

Merge


Changeset: d39227823cae
Author:amurillo
Date:  2015-08-27 14:40 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d39227823cae

Merge

! src/java.base/share/classes/sun/launcher/resources/launcher.properties

Changeset: 4f3c5f831833
Author:amurillo
Date:  2015-08-31 11:26 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4f3c5f831833

Merge

- src/java.base/unix/classes/sun/nio/fs/GnomeFileTypeDetector.java
- src/java.base/unix/native/libnio/fs/GnomeFileTypeDetector.c

Changeset: fd1f5c32751e
Author:dfuchs
Date:  2015-09-01 15:34 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd1f5c32751e

8064470: JNI exception pending in 
jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c
Reviewed-by: alanb, chegar, dfuchs
Contributed-by: vyom.tew

hg: jigsaw/jake/hotspot: 60 new changesets

Changeset: 3c76d8048a58
Author:david
Date:  2015-08-12 16:32 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3c76d8048a58

8133193: Memory leak in G1 because G1RootProcessor doesn't have desctructor
Reviewed-by: mgerdin, tschatzl

! src/share/vm/gc/g1/g1RootProcessor.cpp
! src/share/vm/gc/g1/g1RootProcessor.hpp

Changeset: daa9f374b77c
Author:mockner
Date:  2015-08-12 14:18 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/daa9f374b77c

8098791: Remove PrintClassStatistics and PrintMethodStatistics
Summary: PrintClassStatistics and PrintMethodStatistics have been removed.
Reviewed-by: coleenp, iklam

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/java.cpp

Changeset: 76ac54bf537c
Author:asiebenborn
Date:  2015-08-13 09:32 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/76ac54bf537c

8133121: Move implementation of process_grey_object to concurrentMark.inline.hpp
Summary: move implementation of process_grey_object to inline.hpp
Reviewed-by: kbarrett, simonis

! src/share/vm/gc/g1/concurrentMark.cpp
! src/share/vm/gc/g1/concurrentMark.hpp
! src/share/vm/gc/g1/concurrentMark.inline.hpp

Changeset: 927043f643bc
Author:gziemski
Date:  2015-08-13 17:17 -0500
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/927043f643bc

8112746: Followup to JDK-8059557 (JEP 245)
Summary: Several improvements to range/constraint check feature.
Reviewed-by: coleenp, ddmitriev, sangheki, kbarrett

! src/share/vm/runtime/commandLineFlagConstraintList.cpp
! src/share/vm/runtime/commandLineFlagConstraintList.hpp
! src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp
! src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp
! src/share/vm/runtime/commandLineFlagConstraintsGC.cpp
! src/share/vm/runtime/commandLineFlagConstraintsGC.hpp
! src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
! src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
! src/share/vm/runtime/commandLineFlagRangeList.cpp
! src/share/vm/runtime/commandLineFlagRangeList.hpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp

Changeset: eb1d5a7fc05f
Author:coleenp
Date:  2015-08-13 23:35 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/eb1d5a7fc05f

Merge


Changeset: a3e6c865104c
Author:dholmes
Date:  2015-08-13 22:08 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a3e6c865104c

8029453: java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java failed 
by timeout
Reviewed-by: bdelsart, ddmitriev, dcubed

! src/os/linux/vm/os_linux.cpp

Changeset: f0097a9f4a3f
Author:dholmes
Date:  2015-08-14 04:21 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f0097a9f4a3f

Merge


Changeset: 6ce41ccea6ca
Author:coleenp
Date:  2015-08-14 15:08 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6ce41ccea6ca

8133557: Missing test before a branch when checking for MethodCounters in 
TemplateTable::branch() on x86
Reviewed-by: kvn, coleenp
Contributed-by: richard.reingru...@sap.com

! src/cpu/x86/vm/templateTable_x86.cpp

Changeset: d86f613e4231
Author:coleenp
Date:  2015-08-14 19:23 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d86f613e4231

Merge


Changeset: 17c65a196427
Author:minqi
Date:  2015-08-14 10:10 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/17c65a196427

8130115: REDO - Reduce Symbol::_identity_hash to 2 bytes
Summary: Convert Symbol::_identity_hash from integer to short integer to save 
two bytes. Also change identity_hash() to have 'this' and first two bytes of 
symbol join the calculation.
Reviewed-by: iklam, coleenp, shade

! agent/src/share/classes/sun/jvm/hotspot/debugger/Address.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/dummy/DummyAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgAddress.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java
! src/share/vm/oops/symbol.cpp
! src/share/vm/oops/symbol.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 160f691ef3d0
Author:minqi
Date:  2015-08-14 20:40 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/160f691ef3d0

Merge


Changeset: 4ec8bd17d9e3
Author:minqi
Date:  2015-08-14 22:20 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4ec8bd17d9e3

Merge


Changeset: 90861a3150d0
Author:stefank
Date:  2015-06-29 11:09 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/90861a3150d0

8087323:

hg: jigsaw/jake/jaxws: 2 new changesets

Changeset: 52d9ad2536ba
Author:lana
Date:  2015-09-11 10:26 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/52d9ad2536ba

Added tag jdk9-b81 for changeset 139338618c77

! .hgtags

Changeset: 0f7ed2f66596
Author:mchung
Date:  2015-09-11 17:09 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/0f7ed2f66596

Merge

hg: jigsaw/jake/corba: 2 new changesets

Changeset: c20d8ebddaa6
Author:lana
Date:  2015-09-11 10:26 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/c20d8ebddaa6

Added tag jdk9-b81 for changeset 45c35b7f5b40

! .hgtags

Changeset: 5ac2a88513aa
Author:mchung
Date:  2015-09-11 17:09 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/5ac2a88513aa

Merge

hg: jigsaw/jake: 5 new changesets

Changeset: c356ee0434a0
Author:ihse
Date:  2015-09-03 11:05 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/c356ee0434a0

8062618: Create a build failure summary at end of build log
Reviewed-by: erikj

! make/Init.gmk
! make/InitSupport.gmk
! make/common/JavaCompilation.gmk
! make/common/MakeBase.gmk
! make/common/NativeCompilation.gmk

Changeset: 4a82073cc315
Author:ihse
Date:  2015-09-03 15:01 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/4a82073cc315

8135014: logger.sh needs to handle commands with variable assignment prefixes
Reviewed-by: erikj

! common/bin/logger.sh

Changeset: b8afcf91331d
Author:lana
Date:  2015-09-03 16:11 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/b8afcf91331d

Merge


Changeset: f7ea70a58c53
Author:lana
Date:  2015-09-11 10:26 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/f7ea70a58c53

Added tag jdk9-b81 for changeset b8afcf91331d

! .hgtags

Changeset: 70612266846c
Author:mchung
Date:  2015-09-11 17:09 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/70612266846c

Merge

! make/InitSupport.gmk
! make/common/JavaCompilation.gmk
! make/common/MakeBase.gmk
! make/common/NativeCompilation.gmk

hg: jigsaw/jake/jaxp: 2 new changesets

Changeset: 53fe3c103b6f
Author:lana
Date:  2015-09-11 10:26 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/53fe3c103b6f

Added tag jdk9-b81 for changeset 6a418934997f

! .hgtags

Changeset: faade39222ae
Author:mchung
Date:  2015-09-11 17:09 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/faade39222ae

Merge

Re: Jigsaw EA feedback on running an internal app


Hi Peter,

On 9/11/2015 8:52 AM, Peter Levart wrote:

Spotted an error in "The State of the Module System" document at:
http://openjdk.java.net/projects/jigsaw/spec/sotms/ ... In the "Implied
readability" section, it writes:


The java.sql.Driver interface, in particular, declares the public method

public Logger getParentLogger();

where Logger is a type declared in the exported java.util.logging
package of the java.logging module.

Suppose that code in the com.foo.app module invokes this method in
order to acquire a logger and log a message:

String url = ...;
Properties props = ...;
Driver d = DriverManager.getDriver(url);
Connection c = d.connect(url, props);
d.getParentLogger().info("Connection acquired");

If the com.foo.app module is declared as above then this will not
work: *The getParentLogger method is defined in the Logger class,
which is in the java.logging module, which is not read by the
com.foo.app module. That class is therefore inaccessible to code in
the com.foo.app module and so the invocation of the getParentLogger
method will fail, at both compile time and run time.*



The correct text should be, I think: "The getParentLogger method defined
in Driver class has a signature with a return type of Logger class,
which is in the java.logging module, which is not read by the
com.foo.app module. That class is therefore inaccessible to code in the
com.foo.app module and so the invocation of the .info method will fail,
at both compile time and run time (in case the modules were successfully
compiled together using legacy compiler mode and then their artifacts
split into modules)".


You're right.


The fact is that getParentLogger method can be invoked even though it's
return type is in an unreadable module if the return type is not used in
any way in such invocation. For example:

d.getParentLogger().toString();

(the above assumes that .toString() is declared in Object and not
overridden in Logger). If it is overriden, it can be invoked
nevertheless with the following trick:

((Object) d.getParentLogger()).toString().

The important thing is that Logger as a type must not be referenced in
bytecodes if the bytecodes are in a module that doesn't read
java.logging module.

Am I correct? I have experimented with the EA and this is my experience.
Is the prototype working correctly in this respect?


You're right. The Driver::getParentLogger method IS accessible to the 
caller in the com.foo.app module, but the Logger type IS NOT (and so 
neither is the Logger::info method). Of course, the compiler can 
trivially prove that a cast of any class type (e.g. Logger, as given by 
the signature of Driver::getParentLogger) to Object is legal. Given that 
cast, the compiler will emit an invokevirtual Object::toString, and at 
run time the overriding method will be dynamically dispatched -- could 
be in Logger, could be in a subclass of Logger, but the caller doesn't 
need to know (or have access).



Now just a thought on implied readability. While it is a convenient
feature, it can be dangerous if not used correctly. I think a module
should declare it's own dependencies (requires) for all types it
references explicitly. In above example, it invokes method Loger.info()
and therefore uses types from module java.logging explicitly.

A case where implied readability would be abused could be described in
the following example:

- java.sql module uses java.logging internally and also exposes a method
Driver.getParentLogger() which returns a Logger which is declared in
java.logging module. Therefore java.sql requires *public* java.logging
to imply the readability of java.logging for modules that require only
java.sql and not java.logging explicitly.
- com.foo.internal module requires java.sql and only uses the part of
it's API that doesn't need types from java.logging
- com.foo.internal also uses Logger internally, but fails to declare
this. It nevertheless works since java.logging is implicitly readable to
it through declaration in java.sql
- java.sql module decides to change it's internal use of logging API and
instead of java.logging starts using org.apache.log4j. It now requires
*public* org.apache.log4j instead of java.logging - an incompatible
change, yes, but should not affect com.foo.internal that only uses the
part of it's API that doesn't use types from java.logging
- com.foo.internal now fails because it still uses java.logging, but
implicit readability of it is not provided by java.sql any more. If
com.foo.internal declared explicitly a dependency on java.logging, such
configuration would still work.

So while convenient, implied readability should be used with care.


I would hope that an IDE would raise awareness of the readability 
situation at step 3, where the com.foo.internal module uses Logger from 
a module to which it (com.foo.internal) only has implied readability.


That said, the author of the com.foo.internal module isn't doing 
anything wrong. He's relying on the contract offered by t

Re: jigsaw vs. jsr166 CVS

Your -Xoverride value of .../src/main points to a package hierarchy 
(java/util/...) but it needs to point to a module hierarchy 
(java.base/java/util/...). That's the meaning of " is a directory 
that contains exploded-module directories" in JEP 261.


Alex

On 9/11/2015 4:30 PM, Martin Buchholz wrote:

I tried adding -Xoverride, but it didn't help.

--- build.xml11 Sep 2015 18:43:46 -1.177
+++ build.xml11 Sep 2015 23:17:46 -
@@ -347,6 +347,7 @@
 fork="true">

+  




I can see that the compiler is being invoked like this:
$ ant -v compile -Djdk9.home="$HOME/jdk/jigsaw-b80"
...
 [javac] Compilation arguments:
 [javac] '-d'
 [javac] '/home/martin/jsr166/jigsaw/build/classes'
 [javac] '-classpath'
 [javac] '/home/martin/jsr166/jigsaw/build/classes'
 [javac] '-sourcepath'
 [javac] '/home/martin/jsr166/jigsaw/src/main'
 [javac] '-g:source,lines,vars'
 [javac] '-Xoverride:/home/martin/jsr166/jigsaw/src/main'
 [javac] '-Xprefer:source'
 [javac] '-XDignore.symbol.file=true'
 [javac] '-Xlint:all'
 [javac] '-Werror'
 [javac] '-Xdoclint:all/protected'
 [javac] '-Xmaxerrs'
 [javac] '1000'
 [javac] '-Xmaxwarns'
 [javac] '1000'

Maybe the problem is that the there is *nothing but* overriding source
files here.
Does javac check that its actual argument source files might be in the
Xoverride tree?

Can/should we make jsr166 files itself a sub-module of java.base?
Certainly, here in jsr166-developer-land, we act as if it were so.
We have independent source trees, binary artifacts, etc... must be a
module!?
(You might not allow carving up java.util along module boundaries, but
the reality as reflected in the bug system is that java.util contains
portions of several "modules")
(but oops ... circular dependencies ...)



On Fri, Sep 11, 2015 at 3:49 PM, Alex Buckley mailto:alex.buck...@oracle.com>> wrote:

Hi Martin,

javac is compiling your classes (in the unnamed module) against all
the named modules in the image. One of those named modules
(java.base) contains the java.util package, so your code (in the
unnamed module) cannot also contain that package. [That's not quite
true but go with it for now.]

What you want is the -Xoverride flag -- see the "Overriding module
content" section of JEP 261. You'll have to rename 'main' to
'java.base'. Also note the open design issues around -Xoverride.

Alex


On 9/11/2015 1:51 PM, Martin Buchholz wrote:

Jigsawers:

I tried to use jigsaw EA with jsr166 CVS for the first time.

On a fresh jsr166 CVS checkout
(http://g.oswego.edu/dl/concurrency-interest/),
I did:
   ~/jsr166/jigsaw $ ant -v compile
-Djdk9.home="$HOME/jdk/jigsaw-b80"

and got:

  [javac]
/home/martin/jsr166/jigsaw/src/main/java/util/AbstractQueue.java:7:
warning: package exists in another module: java.base
  [javac] package java.util;

and then more seriously

  [javac]
/home/martin/jsr166/jigsaw/src/main/java/util/AbstractQueue.java:36:
error:
cannot find symbol
  [javac] extends AbstractCollection

I was surprised by that -- we don't fiddle with the boot
environment here.
Is it not allowed to compile sources for which class files are
in the same
package but another module?  Alternatively, does the compile time
environment need to include all the sources for the packages being
compiled, i.e. do I need to add sourcepath for
jdk/src/java.base/share/classes?

(Admittedly, developing jdk sources outside the jdk proper is a
little bit
unusual)

Re: jigsaw vs. jsr166 CVS

2015-09-11 Thread Martin Buchholz

I tried adding -Xoverride, but it didn't help.

--- build.xml 11 Sep 2015 18:43:46 - 1.177
+++ build.xml 11 Sep 2015 23:17:46 -
@@ -347,6 +347,7 @@
fork="true">

+  

I can see that the compiler is being invoked like this:
$ ant -v compile -Djdk9.home="$HOME/jdk/jigsaw-b80"
...
[javac] Compilation arguments:
[javac] '-d'
[javac] '/home/martin/jsr166/jigsaw/build/classes'
[javac] '-classpath'
[javac] '/home/martin/jsr166/jigsaw/build/classes'
[javac] '-sourcepath'
[javac] '/home/martin/jsr166/jigsaw/src/main'
[javac] '-g:source,lines,vars'
[javac] '-Xoverride:/home/martin/jsr166/jigsaw/src/main'
[javac] '-Xprefer:source'
[javac] '-XDignore.symbol.file=true'
[javac] '-Xlint:all'
[javac] '-Werror'
[javac] '-Xdoclint:all/protected'
[javac] '-Xmaxerrs'
[javac] '1000'
[javac] '-Xmaxwarns'
[javac] '1000'

Maybe the problem is that the there is *nothing but* overriding source
files here.
Does javac check that its actual argument source files might be in the
Xoverride tree?

Can/should we make jsr166 files itself a sub-module of java.base?
Certainly, here in jsr166-developer-land, we act as if it were so.
We have independent source trees, binary artifacts, etc... must be a
module!?
(You might not allow carving up java.util along module boundaries, but the
reality as reflected in the bug system is that java.util contains portions
of several "modules")
(but oops ... circular dependencies ...)

On Fri, Sep 11, 2015 at 3:49 PM, Alex Buckley 
wrote:

> Hi Martin,
>
> javac is compiling your classes (in the unnamed module) against all the
> named modules in the image. One of those named modules (java.base) contains
> the java.util package, so your code (in the unnamed module) cannot also
> contain that package. [That's not quite true but go with it for now.]
>
> What you want is the -Xoverride flag -- see the "Overriding module
> content" section of JEP 261. You'll have to rename 'main' to 'java.base'.
> Also note the open design issues around -Xoverride.
>
> Alex
>
>
> On 9/11/2015 1:51 PM, Martin Buchholz wrote:
>
>> Jigsawers:
>>
>> I tried to use jigsaw EA with jsr166 CVS for the first time.
>>
>> On a fresh jsr166 CVS checkout (
>> http://g.oswego.edu/dl/concurrency-interest/),
>> I did:
>>   ~/jsr166/jigsaw $ ant -v compile -Djdk9.home="$HOME/jdk/jigsaw-b80"
>>
>> and got:
>>
>>  [javac]
>> /home/martin/jsr166/jigsaw/src/main/java/util/AbstractQueue.java:7:
>> warning: package exists in another module: java.base
>>  [javac] package java.util;
>>
>> and then more seriously
>>
>>  [javac]
>> /home/martin/jsr166/jigsaw/src/main/java/util/AbstractQueue.java:36:
>> error:
>> cannot find symbol
>>  [javac] extends AbstractCollection
>>
>> I was surprised by that -- we don't fiddle with the boot environment here.
>> Is it not allowed to compile sources for which class files are in the same
>> package but another module?  Alternatively, does the compile time
>> environment need to include all the sources for the packages being
>> compiled, i.e. do I need to add sourcepath for
>> jdk/src/java.base/share/classes?
>>
>> (Admittedly, developing jdk sources outside the jdk proper is a little bit
>> unusual)
>>
>>

Re: jigsaw vs. jsr166 CVS


Hi Martin,

javac is compiling your classes (in the unnamed module) against all the 
named modules in the image. One of those named modules (java.base) 
contains the java.util package, so your code (in the unnamed module) 
cannot also contain that package. [That's not quite true but go with it 
for now.]


What you want is the -Xoverride flag -- see the "Overriding module 
content" section of JEP 261. You'll have to rename 'main' to 
'java.base'. Also note the open design issues around -Xoverride.


Alex

On 9/11/2015 1:51 PM, Martin Buchholz wrote:

Jigsawers:

I tried to use jigsaw EA with jsr166 CVS for the first time.

On a fresh jsr166 CVS checkout (http://g.oswego.edu/dl/concurrency-interest/),
I did:
  ~/jsr166/jigsaw $ ant -v compile -Djdk9.home="$HOME/jdk/jigsaw-b80"

and got:

 [javac]
/home/martin/jsr166/jigsaw/src/main/java/util/AbstractQueue.java:7:
warning: package exists in another module: java.base
 [javac] package java.util;

and then more seriously

 [javac]
/home/martin/jsr166/jigsaw/src/main/java/util/AbstractQueue.java:36: error:
cannot find symbol
 [javac] extends AbstractCollection

I was surprised by that -- we don't fiddle with the boot environment here.
Is it not allowed to compile sources for which class files are in the same
package but another module?  Alternatively, does the compile time
environment need to include all the sources for the packages being
compiled, i.e. do I need to add sourcepath for
jdk/src/java.base/share/classes?

(Admittedly, developing jdk sources outside the jdk proper is a little bit
unusual)

Re: Project Jigsaw: Early-Access Builds available on jdk9.java.net/jigsaw

2015-09-11 Thread Mani Sarkar

Looking forward to it - always a pleasure to help.

Cheers,
Mani

On Fri, Sep 11, 2015 at 11:35 AM, Alan Bateman 
wrote:

>
>
> On 10/09/2015 22:12, Mani Sarkar wrote:
>
>> Jim you stole my thunder and lightening - that was it.
>>
>> Thanks Mani, thanks Jim, this is fixed on the QS page now. I've no doubt
> that in time that there will be much better examples and tutorials, that
> page is just a start.
>
> -Alan
>



-- 
@theNeomatrix369 *  |  **Blog
**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
*  |  **Bitbucket
* * |  **Github
* * |  **LinkedIn
*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

Re: Jigsaw EA feedback for elasticsearch

2015-09-11 Thread Robert Muir

I can workaround this issue by changing the code to not call
setAccessible (and doing class.forName).

I don't know why the existing code does it that way... just another
code change, but I think we are fine!

On Fri, Sep 11, 2015 at 4:58 PM, Robert Muir  wrote:
> On Fri, Sep 11, 2015 at 6:09 AM, Alan Bateman  wrote:
>>
>> I'm not sure that I understand the issue here but just to say that the
>> com.sun.management API is a documented/supported API and it exported by
>> module jdk.management:
>>
>> $ java -listmods:jdk.management
>>
>> jdk.management@9.0
>>   requires public java.management
>>   requires mandated java.base
>>   exports com.sun.management
>>   conceals com.sun.management.internal
>>   provides sun.management.spi.PlatformMBeanProvider with
>> com.sun.management.internal.PlatformMBeanProviderImpl
>>
>
> Here is code that fails:
>
> import java.lang.reflect.*;
> import java.lang.management.*;
>
> public class test {
>   public static void main(String args[]) throws Exception {
> OperatingSystemMXBean osMxBean =
> ManagementFactory.getOperatingSystemMXBean();
> Method getTotalPhysicalMemorySize =
> osMxBean.getClass().getMethod("getTotalPhysicalMemorySize");
> getTotalPhysicalMemorySize.setAccessible(true);
> System.out.println(getTotalPhysicalMemorySize.invoke(osMxBean));
>   }
> }
>
> Exception in thread "main"
> java.lang.reflect.InaccessibleObjectException: Unable to make member
> of class com.sun.management.internal.OperatingSystemImpl accessible:
> module jdk.management does not export com.sun.management.internal to
> 
> at 
> sun.reflect.Reflection.throwInaccessibleObjectException(java.base@9.0/Reflection.java:462)
> at 
> java.lang.reflect.AccessibleObject.checkCanSetAccessible(java.base@9.0/AccessibleObject.java:194)
> at 
> java.lang.reflect.AccessibleObject.setAccessible(java.base@9.0/AccessibleObject.java:157)
> at test.main(test.java:8)

Re: Jigsaw EA feedback for elasticsearch

2015-09-11 Thread Robert Muir

On Fri, Sep 11, 2015 at 6:09 AM, Alan Bateman  wrote:
>
> I'm not sure that I understand the issue here but just to say that the
> com.sun.management API is a documented/supported API and it exported by
> module jdk.management:
>
> $ java -listmods:jdk.management
>
> jdk.management@9.0
>   requires public java.management
>   requires mandated java.base
>   exports com.sun.management
>   conceals com.sun.management.internal
>   provides sun.management.spi.PlatformMBeanProvider with
> com.sun.management.internal.PlatformMBeanProviderImpl
>

Here is code that fails:

import java.lang.reflect.*;
import java.lang.management.*;

public class test {
  public static void main(String args[]) throws Exception {
OperatingSystemMXBean osMxBean =
ManagementFactory.getOperatingSystemMXBean();
Method getTotalPhysicalMemorySize =
osMxBean.getClass().getMethod("getTotalPhysicalMemorySize");
getTotalPhysicalMemorySize.setAccessible(true);
System.out.println(getTotalPhysicalMemorySize.invoke(osMxBean));
  }
}

Exception in thread "main"
java.lang.reflect.InaccessibleObjectException: Unable to make member
of class com.sun.management.internal.OperatingSystemImpl accessible:
module jdk.management does not export com.sun.management.internal to

at 
sun.reflect.Reflection.throwInaccessibleObjectException(java.base@9.0/Reflection.java:462)
at 
java.lang.reflect.AccessibleObject.checkCanSetAccessible(java.base@9.0/AccessibleObject.java:194)
at 
java.lang.reflect.AccessibleObject.setAccessible(java.base@9.0/AccessibleObject.java:157)
at test.main(test.java:8)

jigsaw vs. jsr166 CVS

2015-09-11 Thread Martin Buchholz

Jigsawers:

I tried to use jigsaw EA with jsr166 CVS for the first time.

On a fresh jsr166 CVS checkout (http://g.oswego.edu/dl/concurrency-interest/),
I did:
 ~/jsr166/jigsaw $ ant -v compile -Djdk9.home="$HOME/jdk/jigsaw-b80"

and got:

[javac]
/home/martin/jsr166/jigsaw/src/main/java/util/AbstractQueue.java:7:
warning: package exists in another module: java.base
[javac] package java.util;

and then more seriously

[javac]
/home/martin/jsr166/jigsaw/src/main/java/util/AbstractQueue.java:36: error:
cannot find symbol
[javac] extends AbstractCollection

I was surprised by that -- we don't fiddle with the boot environment here.
Is it not allowed to compile sources for which class files are in the same
package but another module?  Alternatively, does the compile time
environment need to include all the sources for the packages being
compiled, i.e. do I need to add sourcepath for
jdk/src/java.base/share/classes?

(Admittedly, developing jdk sources outside the jdk proper is a little bit
unusual)

Re: CFV: New Jigsaw Committer: Harold Seigel

2015-09-11 Thread Santosh

Yes my vote 

Sent from my iPhone

> On Sep 11, 2015, at 3:43 PM, Mandy Chung  wrote:
> 
> Vote: yes
> 
> Mandy

Re: CFV: New Jigsaw Committer: Harold Seigel

2015-09-11 Thread Mandy Chung

Vote: yes

Mandy

Re: CFV: New Jigsaw Committer: Harold Seigel


Vote: yes

Re: Static layer descriptors

2015-09-11 Thread Ron Pressler

... Alternatively, instead of defining a new file format, is it possible
for a Java agent to set up layers with the reflective API before the
application starts?

In either case, the build tool could generate the layers file/agent.

Ron


Ron Pressler
paralleluniverse.co
@puniverseco  on Twitter

On Fri, Sep 11, 2015 at 8:41 PM, Ron Pressler 
wrote:

> Just finished reading the new Jigsaw information. Great job!
>
> I do have a question regarding version conflicts (as I'm sure do many
> others). The document says Jigsaw leaves the version-selection problem to
> the build too, which fine. But to resolve transitive dependency version
> conflicts -- a --> b, c; b --> d@1; c --> d@2 -- the current solution is
> shading/shadowing (as d@1 and d@2 can be completely different from one
> another).
>
> It seems like layers could provide a better solution, but as I understand,
> there is no way to statically describe a multi-layer configuration (I know
> I'm overloading the Jigsaw term "configuration" here) and pass it on to
> java at the command line -- only dynamically with reflection. Is that
> correct?
>
> If so, could it be possible to add another command line option as an
> alternative to -modulepath, that can take a file with a static description
> of layer configurations?
>
> Ron
>

Static layer descriptors

2015-09-11 Thread Ron Pressler

Just finished reading the new Jigsaw information. Great job!

I do have a question regarding version conflicts (as I'm sure do many
others). The document says Jigsaw leaves the version-selection problem to
the build too, which fine. But to resolve transitive dependency version
conflicts -- a --> b, c; b --> d@1; c --> d@2 -- the current solution is
shading/shadowing (as d@1 and d@2 can be completely different from one
another).

It seems like layers could provide a better solution, but as I understand,
there is no way to statically describe a multi-layer configuration (I know
I'm overloading the Jigsaw term "configuration" here) and pass it on to
java at the command line -- only dynamically with reflection. Is that
correct?

If so, could it be possible to add another command line option as an
alternative to -modulepath, that can take a file with a static description
of layer configurations?

Ron

Re: CFV: New Jigsaw Committer: Harold Seigel

2015-09-11 Thread Roger Riggs


My mistake, Withdrawn,  I am not a jigsaw comitter.

On 9/11/2015 12:44 PM, Roger Riggs wrote:

Vote: yes

On 9/11/2015 12:31 PM, Karen Kinnear wrote:

I hereby nominate Harold Seigel to Jigsaw Committer.

Re: CFV: New Jigsaw Committer: Harold Seigel

2015-09-11 Thread Roger Riggs


Vote: yes

On 9/11/2015 12:31 PM, Karen Kinnear wrote:

I hereby nominate Harold Seigel to Jigsaw Committer.

Re: CFV: New Jigsaw Committer: Harold Seigel

2015-09-11 Thread Jim Laskey (Oracle)

Vote: yes

— Jim

> On Sep 11, 2015, at 1:31 PM, Karen Kinnear  wrote:
> 
> 
> I hereby nominate Harold Seigel to Jigsaw Committer.
> 
> Harold is a member of the hotspot runtime team and a Reviewer on the jdk9 
> project.
> Harold has been contributing to Project Jigsaw in the hotspot runtime for 
> over a
> year, including support for the JVM_* interfaces for modules, boot class 
> loader
> support for jigsaw and handling jvm bootstrapping issues relative to jigsaw 
> that are
> currently prototyped in the jigsaw/jake forest.
> 
> Votes are due by: September 25, 2105 8:00 PST. Only current Jigsaw
> Committers [1] are eligible to vote on this nomination. Votes must be
> cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2]
> 
> thanks,
> Karen
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> 
> Harold's changesets for jigsaw/jake:
> 
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/065aac05e267
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0f0743393dcb
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2779b74ac808
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4399b514d1f6
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4443dde8d089
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/46f34d9a3520
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4c251362419a
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/52aa2e30e139
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5936cfa7957f
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5b987349098f
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5d446c5f5d87
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5fde03772024
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6742fb545950
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/68fec4452b48
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6be1b3b68758
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7227b4dbf763
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/83b7f458698f
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9889c393adfb
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/990036fcd63d
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9959993748a1
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9be9f81cb8e8
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9ddaf93af7e6
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a38181c2fc6d
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a3f86617d287
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a68fdd75403a
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b9882cb01d60
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ccd5acdfc183
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dba44c406ceb
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e49914e2c4ca
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ef26f9d82c61
> http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fb43f332125d
> 
> http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/06c7768ed452
> http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0a4072287a82
> http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/200d3d2c3f9e
> http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4feb32b92512
> http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/585b5b96a990
> http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8ed709fbba55
> http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8fe7c0be60a2
>

CFV: New Jigsaw Committer: Harold Seigel

2015-09-11 Thread Karen Kinnear


I hereby nominate Harold Seigel to Jigsaw Committer.

Harold is a member of the hotspot runtime team and a Reviewer on the jdk9 
project.
Harold has been contributing to Project Jigsaw in the hotspot runtime for over a
year, including support for the JVM_* interfaces for modules, boot class loader
support for jigsaw and handling jvm bootstrapping issues relative to jigsaw 
that are
currently prototyped in the jigsaw/jake forest.

Votes are due by: September 25, 2105 8:00 PST. Only current Jigsaw
Committers [1] are eligible to vote on this nomination. Votes must be
cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [2]

thanks,
Karen
[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote

Harold's changesets for jigsaw/jake:

http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/065aac05e267
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0f0743393dcb
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2779b74ac808
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4399b514d1f6
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4443dde8d089
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/46f34d9a3520
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4c251362419a
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/52aa2e30e139
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5936cfa7957f
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5b987349098f
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5d446c5f5d87
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5fde03772024
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6742fb545950
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/68fec4452b48
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6be1b3b68758
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7227b4dbf763
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/83b7f458698f
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9889c393adfb
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/990036fcd63d
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9959993748a1
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9be9f81cb8e8
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9ddaf93af7e6
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a38181c2fc6d
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a3f86617d287
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a68fdd75403a
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b9882cb01d60
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ccd5acdfc183
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dba44c406ceb
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e49914e2c4ca
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ef26f9d82c61
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fb43f332125d

http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/06c7768ed452
http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0a4072287a82
http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/200d3d2c3f9e
http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4feb32b92512
http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/585b5b96a990
http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8ed709fbba55
http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8fe7c0be60a2

Jigsaw EA feedback on running an internal app

2015-09-11 Thread Peter Levart


Hi,

Excellent work and congratulations on finally bringing modules to Java!

I tried to run a medium-sized stand-alone server application with Jigsaw 
9.0 EA build and it seems to work fine after adding a single 
-XaddExports option. This app uses the following 3rd party 
libraries/components:


Hibernate 4.3
Jasper Reports 4.5
Jetty 6.1.5
JRules 6.7
Spring 4.2
Coherence 3.7
...and lots of other small libraries

All used libraries behave nicely. The 
-XaddExports:java.rmi/sun.rmi.server=ALL-UNNAMED was needed because of 
Oracle Coherence!


Building the app with Maven doesn't work though. Maven compiler module 
doesn't seem to be able to use the javac compiler API correctly. Maven 
folks would have to look at it.


Spotted an error in "The State of the Module System" document at: 
http://openjdk.java.net/projects/jigsaw/spec/sotms/ ... In the "Implied 
readability" section, it writes:



The java.sql.Driver interface, in particular, declares the public method

public Logger getParentLogger();

where Logger is a type declared in the exported java.util.logging 
package of the java.logging module.


Suppose that code in the com.foo.app module invokes this method in 
order to acquire a logger and log a message:


String url = ...;
Properties props = ...;
Driver d = DriverManager.getDriver(url);
Connection c = d.connect(url, props);
d.getParentLogger().info("Connection acquired");

If the com.foo.app module is declared as above then this will not 
work: *The getParentLogger method is defined in the Logger class, 
which is in the java.logging module, which is not read by the 
com.foo.app module. That class is therefore inaccessible to code in 
the com.foo.app module and so the invocation of the getParentLogger 
method will fail, at both compile time and run time.*



The correct text should be, I think: "The getParentLogger method defined 
in Driver class has a signature with a return type of Logger class, 
which is in the java.logging module, which is not read by the 
com.foo.app module. That class is therefore inaccessible to code in the 
com.foo.app module and so the invocation of the .info method will fail, 
at both compile time and run time (in case the modules were successfully 
compiled together using legacy compiler mode and then their artifacts 
split into modules)".


The fact is that getParentLogger method can be invoked even though it's 
return type is in an unreadable module if the return type is not used in 
any way in such invocation. For example:


d.getParentLogger().toString();

(the above assumes that .toString() is declared in Object and not 
overridden in Logger). If it is overriden, it can be invoked 
nevertheless with the following trick:


((Object) d.getParentLogger()).toString().

The important thing is that Logger as a type must not be referenced in 
bytecodes if the bytecodes are in a module that doesn't read 
java.logging module.


Am I correct? I have experimented with the EA and this is my experience. 
Is the prototype working correctly in this respect?


Now just a thought on implied readability. While it is a convenient 
feature, it can be dangerous if not used correctly. I think a module 
should declare it's own dependencies (requires) for all types it 
references explicitly. In above example, it invokes method Loger.info() 
and therefore uses types from module java.logging explicitly.


A case where implied readability would be abused could be described in 
the following example:


- java.sql module uses java.logging internally and also exposes a method 
Driver.getParentLogger() which returns a Logger which is declared in 
java.logging module. Therefore java.sql requires *public* java.logging 
to imply the readability of java.logging for modules that require only 
java.sql and not java.logging explicitly.
- com.foo.internal module requires java.sql and only uses the part of 
it's API that doesn't need types from java.logging
- com.foo.internal also uses Logger internally, but fails to declare 
this. It nevertheless works since java.logging is implicitly readable to 
it through declaration in java.sql
- java.sql module decides to change it's internal use of logging API and 
instead of java.logging starts using org.apache.log4j. It now requires 
*public* org.apache.log4j instead of java.logging - an incompatible 
change, yes, but should not affect com.foo.internal that only uses the 
part of it's API that doesn't use types from java.logging
- com.foo.internal now fails because it still uses java.logging, but 
implicit readability of it is not provided by java.sql any more. If 
com.foo.internal declared explicitly a dependency on java.logging, such 
configuration would still work.


So while convenient, implied readability should be used with care.

Regards, Peter

P.S.

Here's a perl script one can find useful for parsing exception traces 
(from logs for example) and turning them into -XaddExports options that 
allow access to non-public APIs:


#!/bin/perl
my %exports = ();
wh

Re: Groovy with Jigsaw


Am 11.09.2015 14:47, schrieb Alan Bateman:
[...]

It's always been possible to configure the system class loader to be
something else. So I'm curious what you do if it is a URLClassLoader,
are you just looking for the class path?


Then it would not work. But since the cases for @Grab have not been 
cases in which you normally do that, there was almost always the chance 
to do this in practice. Now not anymore. Normally you don't need to do 
this kind of thing either. There is for example GroovyRootLoader, which 
we use to load the Groovy runtime, which is an URLClassLoader and can be 
used... only in some cases like some jdbc drivers you need a higher 
loader and that's where the system class loader was used in the past. 
What is the alternative?



And somebody has to explain to me why this is supposed to be different
for Nashorn. I would imagine it is even worse there, since Nashorn can
see internal APIs, that are hidden to others and since it is part of
the JDK.

Nashorn is updated in the EA builds to work with modules, it is spinning
dynamic modules at run-time. I think it requires building up examples of
real needs before thinking about an API here.


My thought experiment is the following...

Have module A, with internal API in a.internal and public stuff in 
a.public. Furthermore A is written in Groovy. Let us say there is a 
public static method a.internal.BadClass#badMethod(), then any Groovy 
program can do the following: a.internal.BadClass.badMethod(). And that 
is because the method call will be done from Groovy. For A to be working 
there has to be a Groovy module which is allowed to access the internal 
API, since otherwise the classes there won't work.


But maybe this question should go to the expert group instead?

bye Jochen

--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/

Re: Groovy with Jigsaw


Am 11.09.2015 14:29, schrieb Alan Bateman:
[...]

Supporting dynamic languages and creating dynamic modules is very much
an advanced topic at this time and there isn't support in the exported
API for this. There is of course low-level support in the implementation
and you'll find that Proxy and a few other areas that spin classes at
run-time are using it in the current builds.


I will have a look. But this most certainly means we will have to change 
several parts of the code. We use our own class loaders in several 
areas, as well as runtime generated classes.



At this time, if you are spinning classes the same package/loader of
existing modules then those generated classes will be members of the
module.  If you are spinning classes into new packages or different class
loaders that don't have any modules defined to them then they will be in
that loader's unnamed module.


generating classes using a new classloader is the standard for us. That 
is imho the case for our callsite caching, but I am very sure for groovy 
classes compiled and run at runtime. Since there will be several layers 
of code between the place that causes the compilation and execution as 
well as the place that does it I also currently see no way to add 
ourselves like a layer. It would require to be able to know the caller 
class/module or something like this. That is still an unsolved problem 
on the JVM for non-JDK code - imho.


bye Jochen


--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/

Re: Groovy with Jigsaw

2015-09-11 Thread Remi Forax

Jochen,
@CS == @CallerSensitive which means that setAccessible may throw an error 
depending where you call (from which class).

Given that in Guava, setAccessible is called inside the Guava code,
then this guava code may now fail and throw an exception.

Rémi


- Mail original -
> De: "Jochen Theodorou" 
> À: "Alan Bateman" , "Cédric Champeau" 
> 
> Cc: jigsaw-dev@openjdk.java.net
> Envoyé: Vendredi 11 Septembre 2015 11:46:25
> Objet: Re: Groovy with Jigsaw
> 
> Am 11.09.2015 11:33, schrieb Alan Bateman:
> >
> > On 11/09/2015 10:21, Jochen Theodorou wrote:
> >>
> >> the error in Guava is not a failed attempt, it is a VerifyError,
> >> because AccessibleObject#setAccessible is now final and
> >> com.google.common.reflect.Element overrides the method.
> >>
> >> As far as I have seen Guava makes a parallel reflective structure of a
> >> class to be able to better handle them. A the same time they proxy to
> >> their counter parts, but do also implement interfaces like Member.
> >> That requires for example to override setAccessible, which will just
> >> make the same call on the delegate. I don't see how they can easily
> >> fix that without giving up their mirror structure and have it
> >> exchangeable with the java reflective classes at the same time. But I
> >> am not on the guava team, so they know hopefully better
> > Okay, I mis-read one of the mails and assumed that setAccessible was
> > failing and leading to other errors.
> 
> It does fail for any Groovy script, that invokes any method on an
> Object, that has a declaring class, which is made inaccessible through
> the module system, due to the new exception being thrown. Example:
> 
> ClassLoader.getSystemClassLoader().toString()
> 
> > In the current builds then setAccessible is final, and yes, this is an
> > incompatible change. The reason for this is that the method is now @CS.
> > I think we need to consider changing this so that setAccessible is
> > overridden in the final Field, Constructor, and Method classes instead.
> 
> Does @CS then mean guava will then possibly interfere with the security
> manager logic, since it introduces a new layer of calling code in between?
> 
> bye Jochen
> 
> --
> Jochen "blackdrag" Theodorou
> blog: http://blackdragsview.blogspot.com/
> 
>

Re: Groovy with Jigsaw



On 11/09/2015 13:11, Jochen Theodorou wrote:

Am 11.09.2015 13:00, schrieb Uwe Schindler:

Just to conclude, there are 2 problems around setAccessible:

First, it throws a new Exception type. This makes almost any Groovy 
script fail at some point, because it tries to add some meta class on 
the scripting level, and this call setAccessible on all fields and 
methods of any class used in the script, only catching 
SecurityException but not the new one. My preferred solution would be 
to make the new InaccessibleObjectException as subclass of 
SecurityException (and add some documentation why this is done like 
that). Please note this does not differ from current Java 8 spec, 
where setAccessible may throw SecurityException without a security 
manager on some special objects (Class constructor). I agree, this is 
also strange (UOE would be more correct), but the same solution could 
be taken here, too.
Yes, this a incompatible change as InaccessibleObjectException is new. 
We might need to look at this again but changing it to security 
exception (or a sub-type) is really icky. One thing that would be useful 
to find setAccessible usages in other libraries to see if security 
exception is caught or handled.





Second: AccessibleObject#setAccessible was made final
I have a patch to resolve this one, just needs more testing, there was 
no intention to break anyone with this. My guess is that it is is very 
rare to extent AccessibleObject outside of java.lang.reflect.





It doesn't end there. I have yet to investigate what it means if the 
system class loader is no URLClassLoader per default anymore. This 
will have impact on Groovy's @Grab. This will cause problems with for 
example loading jdbc drivers at runtime.
It's always been possible to configure the system class loader to be 
something else. So I'm curious what you do if it is a URLClassLoader, 
are you just looking for the class path?



:

And somebody has to explain to me why this is supposed to be different 
for Nashorn. I would imagine it is even worse there, since Nashorn can 
see internal APIs, that are hidden to others and since it is part of 
the JDK.
Nashorn is updated in the EA builds to work with modules, it is spinning 
dynamic modules at run-time. I think it requires building up examples of 
real needs before thinking about an API here.


-Alan

Re: Groovy with Jigsaw



On 10/09/2015 23:40, Jochen Theodorou wrote:

:

As far as I understood a classloader can have a N modules plus the 
unnamed module. I assume a the children of a classloader do not 
automatically share modules (or not at all?) with their children.
The "Class loaders" section in the SOTMS document provides a good 
summary of the proposed design. The current builds implement this so 
that a module is defined to a class loader. You can't some types in a 
module defined by one class loader and other types in the same module 
defined by a different class loader (how would package private access 
work for example).


I'm sure there will be lots of discussion about class loaders in the JSR.



Do assume right in that there is no way to create a module at runtime?

Next question is about runtime generated classes. And I mean here 
classes generated by user code at runtime, as well as proxies, code 
for reflection and invokedynamic and all the other bytecode generating 
facilities. Will they all go into the unnamed module?
In the proposed design there is a concept of layers of modules. The 
EA/prototype builds have API support for this and you'll find tests in 
the jdk repo that exercise this API to create configurations and 
instantiate them as modules in the run-time.


Supporting dynamic languages and creating dynamic modules is very much 
an advanced topic at this time and there isn't support in the exported 
API for this. There is of course low-level support in the implementation 
and you'll find that Proxy and a few other areas that spin classes at 
run-time are using it in the current builds.


At this time, if you are spinning classes the same package/loader of 
existing modules then those generated classes will be members of the 
module. If you are spinning classes into new packages or different class 
loaders that don't have any modules defined to them then they will be in 
that loader's unnamed module.




Assuming they go there (how else can you choose from those N modules), 
what access rights to the modules will they have? I assume to 
everything that is exported, and for that it does not matter if it is 
the same class loader or a parent or any other loader.
Assuming they created in an unnamed module then it's as per the "Unnamed 
modules" section of the document.


I see you have other questions about Groovy being a man-in-the-middle. I 
don't have time to reply to that now, others have have cycles to engage 
on that topic.


-Alan.

Re: Groovy with Jigsaw


Am 11.09.2015 13:00, schrieb Uwe Schindler:

Just to conclude, there are 2 problems around setAccessible:

First, it throws a new Exception type. This makes almost any Groovy script fail 
at some point, because it tries to add some meta class on the scripting level, 
and this call setAccessible on all fields and methods of any class used in the 
script, only catching SecurityException but not the new one. My preferred 
solution would be to make the new InaccessibleObjectException as subclass of 
SecurityException (and add some documentation why this is done like that). 
Please note this does not differ from current Java 8 spec, where setAccessible 
may throw SecurityException without a security manager on some special objects 
(Class constructor). I agree, this is also strange (UOE would be more correct), 
but the same solution could be taken here, too.

Second: AccessibleObject#setAccessible was made final, this breaks "delegators" 
like the one in Google Guava, which is a library used in like 50% of all larger software 
projects. Changing methods to be final in abstract classes is always a hard break, 
because abstract classes are there to be extended. The workaround may be to make the 
implementations final (which they are already, because Method, Field,... classes are 
final). Maybe just move the implementation into the final subclasses (with stupid code 
duplication, alternatively use a static helper class to avoid the code duplication). We 
had a similar issue in Java 8 EA builds (reported by Lucene at that time), where 
isAnnotationPresent() was moved as *default* method to the interface AnnotatedObject and 
then the impl in Field/Method/... was removed. This caused compiler failures for code 
compiled with source/target 1.7. The fix was to define the method in all subclasses but 
delegate to the interface with some super-like construc

t
.

It doesn't end there. I have yet to investigate what it means if the 
system class loader is no URLClassLoader per default anymore. This will 
have impact on Groovy's @Grab. This will cause problems with for example 
loading jdbc drivers at runtime.


And if the assumptions about the module system in my initial post all 
are correct (nobody commented on those), I see trouble for Groovy 
calling methods in general. If we have to make a Groovy module and 
modules written in Groovy have to allow Groovy access to internal APIs, 
to be able to make normal method calls, then it means the module system 
is bypassed, because then any other Groovy program from any other module 
can use Groovy to access internals. Which also means Java programs can 
use Groovy to exploit everything of any Groovy module.


And somebody has to explain to me why this is supposed to be different 
for Nashorn. I would imagine it is even worse there, since Nashorn can 
see internal APIs, that are hidden to others and since it is part of the 
JDK.


bye blackdrag

--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/

RE: Groovy with Jigsaw

2015-09-11 Thread Uwe Schindler

Just to conclude, there are 2 problems around setAccessible:

First, it throws a new Exception type. This makes almost any Groovy script fail 
at some point, because it tries to add some meta class on the scripting level, 
and this call setAccessible on all fields and methods of any class used in the 
script, only catching SecurityException but not the new one. My preferred 
solution would be to make the new InaccessibleObjectException as subclass of 
SecurityException (and add some documentation why this is done like that). 
Please note this does not differ from current Java 8 spec, where setAccessible 
may throw SecurityException without a security manager on some special objects 
(Class constructor). I agree, this is also strange (UOE would be more correct), 
but the same solution could be taken here, too.

Second: AccessibleObject#setAccessible was made final, this breaks "delegators" 
like the one in Google Guava, which is a library used in like 50% of all larger 
software projects. Changing methods to be final in abstract classes is always a 
hard break, because abstract classes are there to be extended. The workaround 
may be to make the implementations final (which they are already, because 
Method, Field,... classes are final). Maybe just move the implementation into 
the final subclasses (with stupid code duplication, alternatively use a static 
helper class to avoid the code duplication). We had a similar issue in Java 8 
EA builds (reported by Lucene at that time), where isAnnotationPresent() was 
moved as *default* method to the interface AnnotatedObject and then the impl in 
Field/Method/... was removed. This caused compiler failures for code compiled 
with source/target 1.7. The fix was to define the method in all subclasses but 
delegate to the interface with some super-like construct.

Uwe

-
Uwe Schindler
uschind...@apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/

> -Original Message-
> From: Jochen Theodorou [mailto:blackd...@gmx.org]
> Sent: Friday, September 11, 2015 11:46 AM
> To: Alan Bateman; Cédric Champeau
> Cc: Uwe Schindler; jigsaw-dev@openjdk.java.net
> Subject: Re: Groovy with Jigsaw
> 
> Am 11.09.2015 11:33, schrieb Alan Bateman:
> >
> > On 11/09/2015 10:21, Jochen Theodorou wrote:
> >>
> >> the error in Guava is not a failed attempt, it is a VerifyError,
> >> because AccessibleObject#setAccessible is now final and
> >> com.google.common.reflect.Element overrides the method.
> >>
> >> As far as I have seen Guava makes a parallel reflective structure of
> >> a class to be able to better handle them. A the same time they proxy
> >> to their counter parts, but do also implement interfaces like Member.
> >> That requires for example to override setAccessible, which will just
> >> make the same call on the delegate. I don't see how they can easily
> >> fix that without giving up their mirror structure and have it
> >> exchangeable with the java reflective classes at the same time. But I
> >> am not on the guava team, so they know hopefully better
> > Okay, I mis-read one of the mails and assumed that setAccessible was
> > failing and leading to other errors.
> 
> It does fail for any Groovy script, that invokes any method on an Object, that
> has a declaring class, which is made inaccessible through the module system,
> due to the new exception being thrown. Example:
> 
> ClassLoader.getSystemClassLoader().toString()
> 
> > In the current builds then setAccessible is final, and yes, this is an
> > incompatible change. The reason for this is that the method is now @CS.
> > I think we need to consider changing this so that setAccessible is
> > overridden in the final Field, Constructor, and Method classes instead.
> 
> Does @CS then mean guava will then possibly interfere with the security
> manager logic, since it introduces a new layer of calling code in between?
> 
> bye Jochen
> 
> --
> Jochen "blackdrag" Theodorou
> blog: http://blackdragsview.blogspot.com/

Re: Project Jigsaw: Early-Access Builds available on jdk9.java.net/jigsaw




On 10/09/2015 22:12, Mani Sarkar wrote:

Jim you stole my thunder and lightening - that was it.

Thanks Mani, thanks Jim, this is fixed on the QS page now. I've no doubt 
that in time that there will be much better examples and tutorials, that 
page is just a start.


-Alan

Re: Jigsaw EA feedback for elasticsearch

2015-09-11 Thread Robert Muir

On Fri, Sep 11, 2015 at 6:09 AM, Alan Bateman  wrote:

> Just so I understand, the Thai break iterator issue was with the jigsaw EA
> builds and not the regular JDK 9 builds, right? And it only happened once,
> you can't reproduce. This is a bit worrisome. All I can say is that there
> are a lot of changes in this area, a lot of technical debt related to the
> split with the java.base and the jdk.localedata module had to be addressed.
> Off-hand then I can't think of anything that would lead to an intermittent
> issue. If you find out more on this then please send mail.
>

This is difficult to answer. We have been trying to do JDK 9 testing,
but the early access builds have been "broken" from our perspective
all summer long, so we had to disable them because developers were too
confused when tens or hundreds of tests fail.

The major problems were various bugs in System.arraycopy...

Because of that, this one might be a general JDK 9 problem unrelated
to jigsaw. I'll have to spend more time digging into all those items I
listed to try to see exactly what is happening, but those were the
issues I hit when trying to get the jigsaw build to pass the tests.

Re: Jigsaw EA feedback for elasticsearch

Thanks for the great write-up! A few comments below.

On 11/09/2015 06:07, Robert Muir wrote:

2. we have a "jar hell detector" that threw an
UnsupportedOperationException, because classloader is no longer a
URLClassLoader, so we can't get the list of urls. This caused all
tests to fail. I changed the code to parse java.class.path.
Right, code should never assume that the application class loader is a
implemented as a URLClassLoader (more on this in JEP 261).

3. we have a "jvm info" api that provides information about the jvm,
e.g. to assist our engineers in debugging different nodes in the
cluster. it was not prepared to handle UnsupportedOperationException
from RuntimeMXBean.getBootClassPath: I fixed it to fall back to
sun.boot.class.path, otherwise fall back to "unknown".
This is a another behavior change. RuntimeMXBean.getBootClassPath() has
always specified that it can throw UOE but the JDK has not needed to do
this until now. The alternative choice here is to return an empty string
but that might cause issues too.

4. exception serialization tests failed, because we manually serialize
exceptions. We previously used java serialization, but it causes
serious trouble because of backwards compatibility breaks between even
minor jdk versions: this would strike when users try to upgrade their
jvms for nodes in their cluster with a rolling restart. The tests fail
because the stacktrace "loses" stuff after deserialization (the module
version). For now i just disabled the tests on java 9, because I don't
know how we can support e.g. java 8 and java 9 and populate this stuff
"optionally" yet without more digging.
Stack traces have been updated to optionally include the module and
version but this should be a compatible change (except maybe for code
that parses the String representation). As you mention, these tests
would need to be updated any time that there are new fields added to the
serial form (for standard/Java SE types then this should only be major
releases).

5. we have monitoring apis that provide basic system information,
similar to #3, for debugging purposes, and to feed monitoring tools so
people can track the health of the cluster. previously, we used the
sigar library (JNI) for this, but it has bugs that caused users
crashes. So we were forced to limit ourselves to what is provided with
java management apis: which is much less, but we figure it has the
basics. For some very basic stats, this means we also look for
com.sun.management apis
(https://docs.oracle.com/javase/7/docs/jre/api/management/extension/com/sun/management/package-summary.html)
and if they are available, we provide the stuff available there too,
like how much ram is on the machine, swap in use, number of open/max
file descriptors, and so on. We test what is available and what is not
based on platform so we can detect if something changes in the JDK,
like what happens with jigsaw, where they all become unavailable.
I'm not sure that I understand the issue here but just to say that the
com.sun.management API is a documented/supported API and it exported by
module jdk.management:

$ java -listmods:jdk.management

jdk.management@9.0
requires public java.management
requires mandated java.base
exports com.sun.management
conceals com.sun.management.internal
provides sun.management.spi.PlatformMBeanProvider with
com.sun.management.internal.PlatformMBeanProviderImpl

6. cluster snapshot/restore to amazon s3 does not work, because of
their use of internal ssl libraries. I've tried to get them to fix it
for a while now (https://github.com/aws/aws-sdk-java/pull/432). This
is also a serious loss of functionality, if they wont fix it, I guess
we have to fork the aws sdk.
You can workaround this with
-XaddExport:java.base/sun.security.ssl=ALL-UNNAMED of course but much
better if they could understand and remove the dependency on these
internal classes.

8. during testing I hit some kind of bug, where the thai break
iterator returned wrong information. This might be hotspot-related or
something else, and it never reproduced again. We use this check
(https://github.com/apache/lucene-solr/blob/trunk/lucene/analysis/common/src/java/org/apache/lucene/analysis/th/ThaiTokenizer.java#L37-L47)
to see if we can "really" tokenize thai, otherwise we throw an
exception. For some IBM JVM versions at least in the past, they did
not have a breakiterator for thai. I guess it just goes to show the EA
build is really a prototype, and not yet ready to be added to our CI
servers and so on... which is the only way I can ensure this huge
codebase stays working with jigsaw.
Just so I understand, the Thai break iterator issue was with the jigsaw
EA builds and not the regular JDK 9 builds, right? And it only happened
once, you can't reproduce. This is a bit worrisome. All I can say is
that there are a lot of changes in this area, a lot of technical debt
related to the split with the java.base and the jdk.localedata module

Re: Groovy with Jigsaw


Am 11.09.2015 11:33, schrieb Alan Bateman:


On 11/09/2015 10:21, Jochen Theodorou wrote:


the error in Guava is not a failed attempt, it is a VerifyError,
because AccessibleObject#setAccessible is now final and
com.google.common.reflect.Element overrides the method.

As far as I have seen Guava makes a parallel reflective structure of a
class to be able to better handle them. A the same time they proxy to
their counter parts, but do also implement interfaces like Member.
That requires for example to override setAccessible, which will just
make the same call on the delegate. I don't see how they can easily
fix that without giving up their mirror structure and have it
exchangeable with the java reflective classes at the same time. But I
am not on the guava team, so they know hopefully better

Okay, I mis-read one of the mails and assumed that setAccessible was
failing and leading to other errors.


It does fail for any Groovy script, that invokes any method on an 
Object, that has a declaring class, which is made inaccessible through 
the module system, due to the new exception being thrown. Example:


ClassLoader.getSystemClassLoader().toString()


In the current builds then setAccessible is final, and yes, this is an
incompatible change. The reason for this is that the method is now @CS.
I think we need to consider changing this so that setAccessible is
overridden in the final Field, Constructor, and Method classes instead.


Does @CS then mean guava will then possibly interfere with the security 
manager logic, since it introduces a new layer of calling code in between?


bye Jochen

--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/

Re: Groovy with Jigsaw

2015-09-11 Thread Stephen Colebourne

I tried compiling OpenGamma via maven and ran into this straight away:

java.lang.VerifyError: class com.google.common.reflect.Element
overrides final method
java.lang.reflect.AccessibleObject.setAccessible(Z)V
at java.lang.ClassLoader.defineClass1(java.base@9.0/Native Method)
at java.lang.ClassLoader.defineClass(java.base@9.0/ClassLoader.java:820)
at 
java.security.SecureClassLoader.defineClass(java.base@9.0/SecureClassLoader.java:152)

The Guava code is:
  @Override public final void setAccessible(boolean flag) throws
SecurityException {
accessibleObject.setAccessible(flag);
  }

So yes, looking at alternative ways to make that method final is
probably an essential.

Stephen



On 11 September 2015 at 10:33, Alan Bateman  wrote:
>
> On 11/09/2015 10:21, Jochen Theodorou wrote:
>>
>>
>> the error in Guava is not a failed attempt, it is a VerifyError, because
>> AccessibleObject#setAccessible is now final and
>> com.google.common.reflect.Element overrides the method.
>>
>> As far as I have seen Guava makes a parallel reflective structure of a
>> class to be able to better handle them. A the same time they proxy to their
>> counter parts, but do also implement interfaces like Member. That requires
>> for example to override setAccessible, which will just make the same call on
>> the delegate. I don't see how they can easily fix that without giving up
>> their mirror structure and have it exchangeable with the java reflective
>> classes at the same time. But I am not on the guava team, so they know
>> hopefully better
>
> Okay, I mis-read one of the mails and assumed that setAccessible was failing
> and leading to other errors.
>
> In the current builds then setAccessible is final, and yes, this is an
> incompatible change. The reason for this is that the method is now @CS. I
> think we need to consider changing this so that setAccessible is overridden
> in the final Field, Constructor, and Method classes instead.
>
> -Alan

Re: Groovy with Jigsaw



On 11/09/2015 10:21, Jochen Theodorou wrote:


the error in Guava is not a failed attempt, it is a VerifyError, 
because AccessibleObject#setAccessible is now final and 
com.google.common.reflect.Element overrides the method.


As far as I have seen Guava makes a parallel reflective structure of a 
class to be able to better handle them. A the same time they proxy to 
their counter parts, but do also implement interfaces like Member. 
That requires for example to override setAccessible, which will just 
make the same call on the delegate. I don't see how they can easily 
fix that without giving up their mirror structure and have it 
exchangeable with the java reflective classes at the same time. But I 
am not on the guava team, so they know hopefully better
Okay, I mis-read one of the mails and assumed that setAccessible was 
failing and leading to other errors.


In the current builds then setAccessible is final, and yes, this is an 
incompatible change. The reason for this is that the method is now @CS. 
I think we need to consider changing this so that setAccessible is 
overridden in the final Field, Constructor, and Method classes instead.


-Alan

Re: Groovy with Jigsaw


Am 11.09.2015 10:16, schrieb Alan Bateman:

On 11/09/2015 08:47, Cédric Champeau wrote:

For what it's worth, the issue that triggered this conversation is the
one reported by Uwe. For Groovy we have a chicken and egg problem for
testing, because this change breaks Groovy, and Groovy uses Gradle to
build. Since Gradle itself uses Groovy, we have no compatible build
tool to test the fix... So it's very problematic. Also the build that
we set up failed with:

[23:53:08]W:[Gradle failure report] Caused by: java.lang.VerifyError:
class com.google.common.reflect.Element overrides final method
java.lang.reflect.AccessibleObject.setAccessible(Z)V
[23:53:08]W:[Gradle failure report] at
java.lang.ClassLoader.defineClass1(java.base@9.0/Native Method)
[23:53:08]W:[Gradle failure report] at
java.lang.ClassLoader.defineClass(java.base@9.0/ClassLoader.java:820)
[23:53:08]W:[Gradle failure report] at
java.security.SecureClassLoader.defineClass(java.base@9.0/SecureClassLoader.java:152)

Which indicates the change to setAccessible also broke Guava, which is
used by Gradle. So it's going to be very complicated to even try to
fix the issue in those conditions. Anyway, it doesn't seem a good idea
to introduce a new exception type. Even if it is semantically a bit
problematic, wouldn't make ReflectiveOperationException a subclass of
SecurityException an option?

The right exception for this case might need more consideration but I
assume the underlying issue must be a failed attempt to get access to a
member of a type in a non-exported package.

Is there any way to run this with -Dsun.reflect.debugModuleAccessChecks
to see if you get any stack traces to debug this?


the error in Guava is not a failed attempt, it is a VerifyError, because 
AccessibleObject#setAccessible is now final and 
com.google.common.reflect.Element overrides the method.


As far as I have seen Guava makes a parallel reflective structure of a 
class to be able to better handle them. A the same time they proxy to 
their counter parts, but do also implement interfaces like Member. That 
requires for example to override setAccessible, which will just make the 
same call on the delegate. I don't see how they can easily fix that 
without giving up their mirror structure and have it exchangeable with 
the java reflective classes at the same time. But I am not on the guava 
team, so they know hopefully better


bye blackdrag

--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/

RE: Groovy with Jigsaw

2015-09-11 Thread Uwe Schindler

Hi,

>  Caused by: java.lang.VerifyError: class com.google.common.reflect.Element 
> overrides final method java.lang.reflect.AccessibleObject.setAccessible(Z)V

This is caused by the fact that the new JDK makes setAccessible final in the 
base class AccessibleObject. The Google Guava class is a wrapper class around 
any AccessibleObject and delegates all calls to the object behind, while adding 
some convenience methods.

This is a clear backwards compatibility break. Maybe remove the final here! 
Otherwise Guava has to fix the code and completely remove the reflect.Element 
wrapper class (to me it looks useless, it just spares you a few modifier stuff 
because you can call isPublic()).

Uwe

-

Uwe Schindler

uschind...@apache.org 

ASF Member, Apache Lucene PMC / Committer

Bremen, Germany

http://lucene.apache.org/

From: Cédric Champeau [mailto:cedric.champ...@gmail.com] 
Sent: Friday, September 11, 2015 9:47 AM
To: Alan Bateman
Cc: Uwe Schindler; Jochen Theodorou; jigsaw-dev@openjdk.java.net
Subject: Re: Groovy with Jigsaw

For what it's worth, the issue that triggered this conversation is the one 
reported by Uwe. For Groovy we have a chicken and egg problem for testing, 
because this change breaks Groovy, and Groovy uses Gradle to build. Since 
Gradle itself uses Groovy, we have no compatible build tool to test the fix... 
So it's very problematic. Also the build that we set up failed with:

[23:53:08]W:[Gradle failure report] Caused by: 
java.lang.VerifyError: class com.google.common.reflect.Element overrides final 
method java.lang.reflect.AccessibleObject.setAccessible(Z)V

[23:53:08]W:[Gradle failure report]   at 
java.lang.ClassLoader.defineClass1(java.base@9.0/Native Method)

[23:53:08]W:[Gradle failure report]   at 
java.lang.ClassLoader.defineClass(java.base@9.0/ClassLoader.java:820)

[23:53:08]W:[Gradle failure report]   at 
java.security.SecureClassLoader.defineClass(java.base@9.0/SecureClassLoader.java:152)

Which indicates the change to setAccessible also broke Guava, which is used by 
Gradle. So it's going to be very complicated to even try to fix the issue in 
those conditions. Anyway, it doesn't seem a good idea to introduce a new 
exception type. Even if it is semantically a bit problematic, wouldn't make 
ReflectiveOperationException a subclass of SecurityException an option?

2015-09-11 9:39 GMT+02:00 Alan Bateman :

On 10/09/2015 23:57, Uwe Schindler wrote:

:

I also wanted to ask the question: setAccessible() already throws some checked 
exceptions, why invent a new one that’s no longer checked? Could it not simply 
be one already there - one of the checked ones - or a new one just subclassing 
ReflectiveOperationException? This is completely inconsistent to other core 
reflection APIs. Why have a totally unexpected new one?

Right, there is compatibility issue here (third item in the "Risks and 
Assumptions" section of JEP 261 [1]).

The setAccessible methods don't declare any checked exceptions. The only 
exception they declare is SecurityException. This exception make sense when 
running with a security manager and the specified permission check fails. This 
exception is the wrong exception to fail with when the member is not an an 
exported package as this is nothing to do with the security manager. Sadly, 
these methods do throw SecurityException when attempted on a constructor of 
java.lang.Class, I've been trying to dig into the history on this oddity.

Anyway, retrofitting these methods to throw ReflectiveOperationException (or 
sub-type) isn't really an option because this is a checked exception so it 
would add a source compatibility issue to the list. For now, the prototype API 
changes these methods to throw InaccessibleObjectException and we'll have to 
see the impact of this. I hope we aren't force to change this to throw 
SecurityException as it's the wrong exception, but less impact 
compatibility-wise because there is some chance that existing code might handle 
that already.

-Alan.

[1] http://openjdk.java.net/jeps/261

RE: Groovy with Jigsaw

2015-09-11 Thread Uwe Schindler

Hi,

> On 10/09/2015 23:57, Uwe Schindler wrote:
> > :
> >
> > I also wanted to ask the question: setAccessible() already throws 
> > some
> checked exceptions, why invent a new one that’s no longer checked? 
> Could it not simply be one already there - one of the checked ones - 
> or a new one just subclassing ReflectiveOperationException? This is 
> completely inconsistent to other core reflection APIs. Why have a 
> totally unexpected new one?
> >
> >
> Right, there is compatibility issue here (third item in the "Risks and 
> Assumptions" section of JEP 261 [1]).
> 
> The setAccessible methods don't declare any checked exceptions. The 
> only exception they declare is SecurityException. This exception make 
> sense when running with a security manager and the specified 
> permission check fails. This exception is the wrong exception to fail 
> with when the member is not an an exported package as this is nothing 
> to do with the security manager. Sadly, these methods do throw 
> SecurityException when attempted on a constructor of java.lang.Class, 
> I've been trying to dig into the history on this oddity.

Sorry I missed that. You are right, setAccessible does not throw any checked 
reflective Exception. I was under the impression it might throw 
IllegalAccessException or the like, sorry for that. But the issue still 
persists!

One solution to solve the problem would be to make the 
java.lang.reflect.InaccessibleObjectException a subclass of SecurityException? 
This also looks not ideal, but this would fix all code which is well behaved 
and catches SecurityException on setAccessible. And simple googling shows tons 
of this.

You may add this to the Javadocs of this method and to the documentation of the 
Exception, explaining that it is a subclass of SecurityException for backwards 
compatibility. Are there any other places where 
java.lang.reflect.InaccessibleObjectException is used?

> Anyway, retrofitting these methods to throw 
> ReflectiveOperationException (or sub-type) isn't really an option 
> because this is a checked exception so it would add a source 
> compatibility issue to the list. For now, the prototype API changes 
> these methods to throw InaccessibleObjectException and we'll have to 
> see the impact of this. I hope we aren't force to change this to throw 
> SecurityException as it's the wrong exception, but less impact 
> compatibility- wise because there is some chance that existing code might 
> handle that already.

I agree, maybe add new exception as described above.

> -Alan.
> 
> [1] http://openjdk.java.net/jeps/261

Thanks, very helpful. So looks like setAccessible is the only affected method.

Re: Groovy with Jigsaw


On 11/09/2015 08:47, Cédric Champeau wrote:
For what it's worth, the issue that triggered this conversation is the 
one reported by Uwe. For Groovy we have a chicken and egg problem for 
testing, because this change breaks Groovy, and Groovy uses Gradle to 
build. Since Gradle itself uses Groovy, we have no compatible build 
tool to test the fix... So it's very problematic. Also the build that 
we set up failed with:


[23:53:08]W:[Gradle failure report] Caused by: java.lang.VerifyError: 
class com.google.common.reflect.Element overrides final method 
java.lang.reflect.AccessibleObject.setAccessible(Z)V
[23:53:08]W:[Gradle failure report] at 
java.lang.ClassLoader.defineClass1(java.base@9.0/Native Method)
[23:53:08]W:[Gradle failure report] at 
java.lang.ClassLoader.defineClass(java.base@9.0/ClassLoader.java:820)
[23:53:08]W:[Gradle failure report] at 
java.security.SecureClassLoader.defineClass(java.base@9.0/SecureClassLoader.java:152)


Which indicates the change to setAccessible also broke Guava, which is 
used by Gradle. So it's going to be very complicated to even try to 
fix the issue in those conditions. Anyway, it doesn't seem a good idea 
to introduce a new exception type. Even if it is semantically a bit 
problematic, wouldn't make ReflectiveOperationException a subclass of 
SecurityException an option?
The right exception for this case might need more consideration but I 
assume the underlying issue must be a failed attempt to get access to a 
member of a type in a non-exported package.


Is there any way to run this with -Dsun.reflect.debugModuleAccessChecks 
to see if you get any stack traces to debug this?


-Alan

Re: Project Jigsaw: Early-Access Builds available on jdk9.java.net/jigsaw



On 10/09/2015 22:21, Mani Sarkar wrote:

Hi Alan,

Thanks for the detailed explanation and it would be great to find this 
in your docs - I will link to it.


The reasons I understood, jimage might go away, as I read this 
https://bugs.*openjdk*.java.net/browse/JDK-8049369 
.


Yeah, it is confusing. That JBS issue tracked the creation of temporary 
image builder tool to use in JDK 9 until we had jlink. In jigsaw/jake 
then this image building tool has been removed and the build changed to 
create the run-time images with jlink. The Dependences section of JEP 
261 has a few words on this.


-Alan.

Re: jigsaw EA feedback for Eclipse/JBoss Tools and WildFly

2015-09-11 Thread Rory O'Donnell


Thanks for the update Martin!

On 11/09/2015 08:30, Martin Malina wrote:
On 10. 9. 2015, at 15:41, Alan Bateman > wrote:



On 10/09/2015 14:21, Rory O'Donnell wrote:
Martin - thanks for your feedback, not sure your email made it to 
the list without subscribing.


It will now, rgds Rory
On 10/09/2015 13:59, Martin Malina wrote:


I reported it here: https://issues.jboss.org/browse/JBIDE-20635


Thanks for forwarding. The interesting line seems to be:

13:03:04,020 ERROR [org.jboss.as.controller] (Controller Boot Thread) 
WFLYCTL0002: Error booting the container: 
java.lang.IllegalAccessError: Class __redirected.__XMLInputFactory 
can not access a member of class 
com.sun.xml.internal.stream.XMLInputFactoryImpl (module java.xml) 
with modifiers "public", module java.xml does not export 
com.sun.xml.internal.stream to 


So __redirected.__XMLInputFactory (WildFly?, generated?) is 
attempting to use Class.newInstance to instantiate 
com.sun.xml.internal.stream.XMLInputFactoryImpl. This should fail 
with IllegalAccessException because com.sun.xml.internal.stream is 
not exported. I can't tell where IllegalAccessError is coming from, 
maybe someone is catching IllegalAccessException and re-throwing it 
as an IllegalAccessError.


I assume using -XaddExports can be used to workaround this temporarily.


Hi Alan, thanks for your suggestion. But in this case it seems that 
our Eclipse tooling was at fault. Given the fact that it worked on 
command line, there must have been some difference which broke it in 
Eclipse. Rob seems to have found it and fixed it: 
https://issues.jboss.org/browse/JBIDE-20635


Thanks,
Martin



-Alan.





--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

Re: Groovy with Jigsaw

2015-09-11 Thread Cédric Champeau

For what it's worth, the issue that triggered this conversation is the one
reported by Uwe. For Groovy we have a chicken and egg problem for testing,
because this change breaks Groovy, and Groovy uses Gradle to build. Since
Gradle itself uses Groovy, we have no compatible build tool to test the
fix... So it's very problematic. Also the build that we set up failed with:

[23:53:08]W: [Gradle failure report] Caused by: java.lang.VerifyError:
class com.google.common.reflect.Element overrides final method
java.lang.reflect.AccessibleObject.setAccessible(Z)V
[23:53:08]W: [Gradle failure report] at
java.lang.ClassLoader.defineClass1(java.base@9.0/Native Method)
[23:53:08]W: [Gradle failure report] at
java.lang.ClassLoader.defineClass(java.base@9.0/ClassLoader.java:820)
[23:53:08]W: [Gradle failure report] at
java.security.SecureClassLoader.defineClass(java.base@9.0
/SecureClassLoader.java:152)

Which indicates the change to setAccessible also broke Guava, which is used
by Gradle. So it's going to be very complicated to even try to fix the
issue in those conditions. Anyway, it doesn't seem a good idea to introduce
a new exception type. Even if it is semantically a bit problematic,
wouldn't make ReflectiveOperationException a subclass of SecurityException
an option?


2015-09-11 9:39 GMT+02:00 Alan Bateman :

> On 10/09/2015 23:57, Uwe Schindler wrote:
>
>> :
>>
>> I also wanted to ask the question: setAccessible() already throws some
>> checked exceptions, why invent a new one that’s no longer checked? Could it
>> not simply be one already there - one of the checked ones - or a new one
>> just subclassing ReflectiveOperationException? This is completely
>> inconsistent to other core reflection APIs. Why have a totally unexpected
>> new one?
>>
>>
>> Right, there is compatibility issue here (third item in the "Risks and
> Assumptions" section of JEP 261 [1]).
>
> The setAccessible methods don't declare any checked exceptions. The only
> exception they declare is SecurityException. This exception make sense when
> running with a security manager and the specified permission check fails.
> This exception is the wrong exception to fail with when the member is not
> an an exported package as this is nothing to do with the security manager.
> Sadly, these methods do throw SecurityException when attempted on a
> constructor of java.lang.Class, I've been trying to dig into the history on
> this oddity.
>
> Anyway, retrofitting these methods to throw ReflectiveOperationException
> (or sub-type) isn't really an option because this is a checked exception so
> it would add a source compatibility issue to the list. For now, the
> prototype API changes these methods to throw InaccessibleObjectException
> and we'll have to see the impact of this. I hope we aren't force to change
> this to throw SecurityException as it's the wrong exception, but less
> impact compatibility-wise because there is some chance that existing code
> might handle that already.
>
> -Alan.
>
> [1] http://openjdk.java.net/jeps/261
>

Re: Groovy with Jigsaw


On 10/09/2015 23:57, Uwe Schindler wrote:

:

I also wanted to ask the question: setAccessible() already throws some checked 
exceptions, why invent a new one that’s no longer checked? Could it not simply 
be one already there - one of the checked ones - or a new one just subclassing 
ReflectiveOperationException? This is completely inconsistent to other core 
reflection APIs. Why have a totally unexpected new one?


Right, there is compatibility issue here (third item in the "Risks and 
Assumptions" section of JEP 261 [1]).


The setAccessible methods don't declare any checked exceptions. The only 
exception they declare is SecurityException. This exception make sense 
when running with a security manager and the specified permission check 
fails. This exception is the wrong exception to fail with when the 
member is not an an exported package as this is nothing to do with the 
security manager. Sadly, these methods do throw SecurityException when 
attempted on a constructor of java.lang.Class, I've been trying to dig 
into the history on this oddity.


Anyway, retrofitting these methods to throw ReflectiveOperationException 
(or sub-type) isn't really an option because this is a checked exception 
so it would add a source compatibility issue to the list. For now, the 
prototype API changes these methods to throw InaccessibleObjectException 
and we'll have to see the impact of this. I hope we aren't force to 
change this to throw SecurityException as it's the wrong exception, but 
less impact compatibility-wise because there is some chance that 
existing code might handle that already.


-Alan.

[1] http://openjdk.java.net/jeps/261

hg: jigsaw/jake/nashorn: Aligning jake build changes with jdk9 PathList make macro

Changeset: dbb145cb2c85
Author:erikj
Date:  2015-09-09 18:38 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/dbb145cb2c85

Aligning jake build changes with jdk9 PathList make macro

! make/BuildNashorn.gmk

hg: jigsaw/jake/langtools: Aligning jake build changes with jdk9 PathList make macro

Changeset: 2ca32a0790e4
Author:erikj
Date:  2015-09-09 18:38 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2ca32a0790e4

Aligning jake build changes with jdk9 PathList make macro

! make/CompileInterim.gmk

hg: jigsaw/jake/jdk: 2 new changesets

Changeset: c35f2ffc77f8
Author:erikj
Date:  2015-09-09 18:38 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c35f2ffc77f8

Aligning jake build changes with jdk9 PathList make macro

! make/Tools.gmk
! make/gendata/GendataBreakIterator.gmk
! make/gensrc/GensrcSwing.gmk
! make/rmic/RmicCommon.gmk

Changeset: e4e6bc6fdcb3
Author:erikj
Date:  2015-09-11 09:12 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e4e6bc6fdcb3

Merge

hg: jigsaw/jake: Aligning jake build changes with jdk9 PathList make macro