Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes
Jason Greene wrote: There is also a disparity here that the JDK itself doesn’t require you to export packages (e.g. I don’t need it for Java serialization). Now I realize that there is an effort underway to de-privilege modules, but I suspect that a portion of the JDK will continue to enjoy special power for precisely the same usability concerns that apply to frameworks / standards which extend the platform. I think this a very important point. If someone wanted to reimplement Java serialization (java.io.ObjectOutputStream, etc.) as an external library (com.foo.ObjectOutputStream, etc.), the new restrictions on reflective access in JDK 9 would prevent this. Simon
Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes
On 08/07/2016 20:38, Jason Greene wrote: Now I realize that there is an effort underway to de-privilege modules, but I suspect that a portion of the JDK will continue to enjoy special power for precisely the same usability concerns that apply to frameworks / standards which extend the platform. Just on terminology again. The effort to "de-privilege" modules defence-in-depth where we have been moving the non-core modules out of the boot loader (where they have all security permissions) to the platform class loader where they can be configured with less (and if possible minimum) security permissions. As regards "enjoy special power" then the only module that is known to the VM and module system is "java.base". The java.base module, as you probably know, is the core of the system. The java.base modules has the VM, java.lang.**, the implementation of core reflection, method handles, and everything else that make up the core runtime and APIs. The other 70 or so standard and JDK-specific modules [1] are just modules, no different to user modules that are deployed on the application module path. -Alan [1] http://openjdk.java.net/jeps/200
Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes
On 08/07/2016 22:42, Paul Benedict wrote: : 2) Allow layers to control if non-exported types can be reflected. Perhaps the JDK sets its own layers to "false", but Containers and what they deploy can be separately configured, each. A container or anything else doing dynamic configuration today provides the module finders and so gets an opportunity to re-write module descriptors if it really wants to. So if someone really wants every module in the configuration to export every package then it is possible. It's a bit of effort of course but it seems better than introducting inconsistencies into how core reflection does access checks vs. the VM and method handles. -Alan
Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes
On 09/07/2016 08:46, Simon Nash wrote: I think this a very important point. If someone wanted to reimplement Java serialization (java.io.ObjectOutputStream, etc.) as an external library (com.foo.ObjectOutputStream, etc.), the new restrictions on reflective access in JDK 9 would prevent this. If there are types in non-exported packages in the serial form then it could be an issue. Some serialization libraries are based on Unsafe and sun.reflect.ReflectionFactory, both "critical internal APIs" that continue to be available via the jdk.unsupported module. More on this in JEP 260 [1]. -Alan [1] http://openjdk.java.net/jeps/260
Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes
Alan Bateman wrote: On 09/07/2016 08:46, Simon Nash wrote: I think this a very important point. If someone wanted to reimplement Java serialization (java.io.ObjectOutputStream, etc.) as an external library (com.foo.ObjectOutputStream, etc.), the new restrictions on reflective access in JDK 9 would prevent this. If there are types in non-exported packages in the serial form then it could be an issue. Some serialization libraries are based on Unsafe and sun.reflect.ReflectionFactory, both "critical internal APIs" that continue to be available via the jdk.unsupported module. More on this in JEP 260 [1]. -Alan [1] http://openjdk.java.net/jeps/260 Is it really a good idea to encourage packages that currently use reflection to access non-exported private fields (an official part of the Java API) to change to using internal APIs? This seems like a step backwards to me. Simon
Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes
On 09/07/2016 09:57, Simon Nash wrote: Is it really a good idea to encourage packages that currently use reflection to access non-exported private fields (an official part of the Java API) to change to using internal APIs? This seems like a step backwards to me. I didn't suggest that. I was just pointing out that some of the 3rd party serialization libraries that we've come across are based on Unsafe and ReflectionFactory and the latter is specifically on critical internal API for that reason. -Alan
Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes
On 09.07.2016 09:50, Alan Bateman wrote: [...] As regards "enjoy special power" then the only module that is known to the VM and module system is "java.base". The java.base module, as you probably know, is the core of the system. The java.base modules has the VM, java.lang.**, the implementation of core reflection, method handles, and everything else that make up the core runtime and APIs. The other 70 or so standard and JDK-specific modules [1] are just modules, no different to user modules that are deployed on the application module path. -Alan [1] http://openjdk.java.net/jeps/200 ok, let us assume I want to write a library that does what reflection can do today using bytecode generation. And let us assume I write a library, that will use this reflective module to call from private API to private API. How do we configure the two modules and what, besides the bytecode generation and the api, does the reflective library have to do (layers for example)? Would that have the same power as core reflection as far as the module system is concerned? Since core reflection is in java.base, there is the assumption it enjoys special powers with regards to the module system. And that is especially because something like the layer system is still to unclear. Oh... and let us assume there are two modules using this reflective module configured to be able to access their hidden API using the reflective library. Would this automatically allow the two libraries to call into the other hidden library? bye Jochen
hg: jigsaw/jake/corba: 2 new changesets
Changeset: 8fab452b6f47 Author:amurillo Date: 2016-07-07 18:21 + URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/8fab452b6f47 Added tag jdk-9+126 for changeset c7f5ba08fcd4 ! .hgtags Changeset: 80cd54e85502 Author:alanb Date: 2016-07-09 10:11 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/80cd54e85502 Merge
hg: jigsaw/jake/jaxp: 3 new changesets
Changeset: 15722f71281f Author:amlu Date: 2016-07-05 09:15 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/15722f71281f 8156598: Use more informative format for problem list Reviewed-by: lancea ! test/ProblemList.txt Changeset: 4f80ad5cc0f3 Author:amurillo Date: 2016-07-07 18:21 + URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/4f80ad5cc0f3 Added tag jdk-9+126 for changeset 15722f71281f ! .hgtags Changeset: 26d50fcb6b22 Author:alanb Date: 2016-07-09 10:11 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/26d50fcb6b22 Merge
hg: jigsaw/jake/jaxws: 2 new changesets
Changeset: 06d706c70634 Author:amurillo Date: 2016-07-07 18:21 + URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/06d706c70634 Added tag jdk-9+126 for changeset 264a44128cd6 ! .hgtags Changeset: 5419b0c050e0 Author:alanb Date: 2016-07-09 10:11 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/5419b0c050e0 Merge
hg: jigsaw/jake: 27 new changesets
Changeset: 31261e7238af Author:erikj Date: 2016-06-28 14:20 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/31261e7238af 8160285: Bootcycle builds are broken on jdk9/hs for windows i586 Reviewed-by: dholmes ! common/autoconf/boot-jdk.m4 ! common/autoconf/bootcycle-spec.gmk.in ! common/autoconf/generated-configure.sh Changeset: 20f1ee2fe834 Author:simonis Date: 2016-06-28 16:04 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/20f1ee2fe834 8160423: Serieal build is broken because of missing dependencies for jmod Reviewed-by: erikj ! make/Main.gmk Changeset: 7cd263acb48d Author:erikj Date: 2016-06-29 20:00 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7cd263acb48d 8160571: Bootcycle builds still broken with server jvm on Windows 32bit Reviewed-by: tbell ! common/autoconf/boot-jdk.m4 ! common/autoconf/bootcycle-spec.gmk.in ! common/autoconf/generated-configure.sh Changeset: 044ba47e4f8d Author:lmesnik Date: 2016-06-07 12:55 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/044ba47e4f8d 8154209: Remove client VM from default JIB profile on windows-x86 and linux-x86 Reviewed-by: dholmes ! common/conf/jib-profiles.js ! make/jprt.properties Changeset: f22fad857554 Author:simonis Date: 2016-06-07 18:25 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f22fad857554 8158938: AIX: some more new hotspot build fixes Reviewed-by: erikj ! common/autoconf/build-performance.m4 ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot.m4 Changeset: 77ae814c0f38 Author:erikj Date: 2016-06-07 19:05 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/77ae814c0f38 Merge Changeset: 372de3fbcf88 Author:simonis Date: 2016-06-07 22:01 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/372de3fbcf88 8158763: --disable-hotspot-gtest not working on Solaris Reviewed-by: dholmes ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: cd05b3e4720c Author:amurillo Date: 2016-06-10 15:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/cd05b3e4720c Merge ! common/autoconf/build-performance.m4 ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 ! common/conf/jib-profiles.js Changeset: 114b709abea1 Author:jmasa Date: 2016-06-10 11:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/114b709abea1 8026752: Cancel MetaspaceGC request for a CMS concurrent collection after GC Reviewed-by: sjohanss, sangheki ! test/lib/sun/hotspot/WhiteBox.java Changeset: 5d2c504ff630 Author:jmasa Date: 2016-06-10 15:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5d2c504ff630 Merge ! test/lib/sun/hotspot/WhiteBox.java Changeset: f66462e24f71 Author:jmasa Date: 2016-06-11 00:12 + URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f66462e24f71 Merge Changeset: bfe45d45e2a1 Author:lmesnik Date: 2016-06-17 13:05 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/bfe45d45e2a1 8157831: JVMCI tests should not be executed on linux-arm32 Reviewed-by: dpochepk, dholmes ! test/jtreg-ext/requires/VMProps.java Changeset: 4a042dae129c Author:mchernov Date: 2016-06-17 18:45 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/4a042dae129c 8158412: [TESTBUG] TestIHOPErgo and TestStressG1Humongous should not be executed when JFR is enabled Reviewed-by: dfazunen, tschatzl ! test/jtreg-ext/requires/VMProps.java Changeset: 65471bb982b2 Author:amurillo Date: 2016-06-23 17:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/65471bb982b2 Merge ! common/autoconf/generated-configure.sh Changeset: b1b6e7556b30 Author:amurillo Date: 2016-06-29 21:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/b1b6e7556b30 Merge ! common/autoconf/generated-configure.sh Changeset: c86754a95bc0 Author:amurillo Date: 2016-06-30 22:38 + URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c86754a95bc0 Merge Changeset: b850128d2b85 Author:erikj Date: 2016-07-01 17:03 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/b850128d2b85 8160722: Module summary generation fails on Windows 32bit Reviewed-by: tbell ! common/autoconf/spec.gmk.in Changeset: 9c052d5c4931 Author:erikj Date: 2016-07-01 18:29 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/9c052d5c4931 8160728: Update compare script to clean baseline Reviewed-by: tbell ! common/bin/compare.sh Changeset: 3a58466296d3 Author:bpb Date: 2016-07-01 12:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3a58466296d3 8160018: (fs) Remove GioFileTypeDetector on Solaris Summary: Remove the GioFileTypeDetector from the chain of FileTypeDetectors provided by SolarisFileSystemProvider. Reviewed-by: rriggs ! make/CompileJavaModules.gmk Changeset: 91
hg: jigsaw/jake/nashorn: 5 new changesets
Changeset: bf76248bbe51 Author:hannesw Date: 2016-06-28 15:17 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/bf76248bbe51 8160435: Source.baseURL is slow for URLs with unregistered protocol Reviewed-by: sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Source.java Changeset: a0d37d08c989 Author:tbell Date: 2016-06-29 07:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a0d37d08c989 8160505: Automated test runs fail in nashorn because TEST_IMAGE_DIR is set by jib Reviewed-by: erikj, sundar ! test/Makefile Changeset: ee90c69a1840 Author:amurillo Date: 2016-06-30 22:38 + URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ee90c69a1840 Merge Changeset: ff07be6106fa Author:amurillo Date: 2016-07-07 18:21 + URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ff07be6106fa Added tag jdk-9+126 for changeset ee90c69a1840 ! .hgtags Changeset: a822599405dd Author:alanb Date: 2016-07-09 10:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a822599405dd Merge ! .hgtags ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Source.java
hg: jigsaw/jake/jdk: 83 new changesets
Changeset: 44327147adc2 Author:sherman Date: 2016-06-27 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/44327147adc2 8160312: ArrayIndexOutOfBoundsException when comparing strings case insensitive Reviewed-by: rriggs ! src/java.base/share/classes/java/lang/StringLatin1.java ! test/java/lang/String/CompareIC.java Changeset: 8b6322c3adfc Author:redestad Date: 2016-06-28 00:39 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8b6322c3adfc 816: Runtime.version() cause startup regressions in 9+119 Reviewed-by: mchung, psandoz, erikj, forax, iris ! make/gensrc/GensrcMisc.gmk ! src/java.base/share/classes/java/lang/Runtime.java ! src/java.base/share/classes/java/lang/VersionProps.java.template Changeset: 58bc26407b84 Author:mchung Date: 2016-06-27 20:22 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/58bc26407b84 8159596: Add java --dry-run Reviewed-by: alanb, ksrini ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/native/libjli/java.c + test/tools/launcher/modules/dryrun/DryRunTest.java + test/tools/launcher/modules/dryrun/src/m/module-info.java + test/tools/launcher/modules/dryrun/src/m/p/Lib.java + test/tools/launcher/modules/dryrun/src/test/jdk/test/Main.java + test/tools/launcher/modules/dryrun/src/test/module-info.java Changeset: 3279c9730738 Author:sundar Date: 2016-06-28 09:57 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3279c9730738 8160346: JLinkTest.java should compute exact number of plugins from jdk.jlink module Reviewed-by: jlaskey, mchung ! test/tools/jlink/JLinkTest.java Changeset: 2ec3fa3860f7 Author:rgoel Date: 2016-06-28 13:47 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2ec3fa3860f7 8158504: test/sun/util/locale/provider/Bug8038436.java: non English locale(s) included in available locales Reviewed-by: okutsu, naoto ! test/sun/util/locale/provider/Bug8038436.java Changeset: 73e1dc20396a Author:amlu Date: 2016-06-28 14:39 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/73e1dc20396a 8156536: Remove intermittent key from TreeTest.java and move back to tier1 Reviewed-by: darcy ! test/TEST.groups ! test/java/lang/ProcessHandle/TreeTest.java Changeset: d473607154f0 Author:rpatil Date: 2016-06-27 11:52 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d473607154f0 8153955: increase java.util.logging.FileHandler MAX_LOCKS limit Summary: This patch adds a new configurable property "java.util.logging.FileHandler.maxLocks" to java.util.logging.FileHandler which can be defined in the logging configuration file and makes it possible to configure the maximum number of concurrent log file locks a FileHandler can handle. If not overridden, the default value of maxLocks (100) remains unchanged. Reviewed-by: dfuchs, coffeys ! src/java.logging/share/classes/java/util/logging/FileHandler.java ! src/java.logging/share/conf/logging.properties + test/java/util/logging/FileHandlerMaxLocksTest.java Changeset: 5cfbcb4e6009 Author:jlaskey Date: 2016-06-28 16:07 -0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5cfbcb4e6009 8160459: jlink minor code clean up Reviewed-by: mchung ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/AbstractModuleEntry.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Archive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ArchiveEntryModuleEntry.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/BasicImageWriter.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ByteArrayModuleEntry.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/DirArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageStringsWriter.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JarArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JmodArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ModularJarArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ModuleEntryFactory.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ModulePoolImpl.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PathModuleEntry.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePrevisitor.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Utils.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/packager/AppRuntimeImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompre
hg: jigsaw/jake/hotspot: 159 new changesets
Changeset: c73e8464b2e1 Author:shade Date: 2016-06-06 22:34 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c73e8464b2e1 8075030: JvmtiEnv::GetObjectSize reports incorrect java.lang.Class instance size Reviewed-by: coleenp, sspitsyn, sla ! src/share/vm/prims/jvmtiEnv.cpp + test/serviceability/jvmti/GetObjectSizeClass.java + test/serviceability/jvmti/GetObjectSizeClassAgent.java Changeset: 2487dfedce36 Author:mgronlun Date: 2016-06-06 20:48 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2487dfedce36 8149803: Adjust lock rankings for some Event-based tracing locks Reviewed-by: dholmes, acorn ! src/share/vm/runtime/mutexLocker.cpp Changeset: e159d30b22c0 Author:mgronlun Date: 2016-06-07 01:58 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e159d30b22c0 Merge Changeset: b35888b0cb05 Author:ccheung Date: 2016-06-06 12:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b35888b0cb05 8153876: Replace 4K stack allocations with Resource allocations Reviewed-by: dholmes, hseigel ! src/share/vm/classfile/classLoader.cpp Changeset: bf38f95751c8 Author:ccheung Date: 2016-06-07 00:06 + URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bf38f95751c8 Merge Changeset: 51459bc91863 Author:ccheung Date: 2016-06-07 00:57 + URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/51459bc91863 Merge Changeset: 0b039611894c Author:lmesnik Date: 2016-06-07 12:55 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0b039611894c 8154209: Remove client VM from default JIB profile on windows-x86 and linux-x86 Reviewed-by: dholmes ! test/runtime/SharedArchiveFile/DefaultUseWithClient.java Changeset: 064d10f293f5 Author:simonis Date: 2016-06-07 18:26 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/064d10f293f5 8158938: AIX: some more new hotspot build fixes Reviewed-by: erikj ! make/lib/JvmOverrideFiles.gmk Changeset: e8444d8b2be6 Author:erikj Date: 2016-06-07 19:05 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e8444d8b2be6 Merge Changeset: 93c0acb58b92 Author:rprotacio Date: 2016-06-07 11:39 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/93c0acb58b92 8153858: Clean up needed when obtaining the package name from a fully qualified class name Summary: Consolidated and refactored code parsing fully qualified names. Includes gtest. Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionaryShared.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/method.hpp + test/native/runtime/test_classLoader.cpp + test/native/runtime/test_instanceKlass.cpp Changeset: 670fab077f4d Author:rprotacio Date: 2016-06-07 18:17 + URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/670fab077f4d Merge Changeset: 60b4f0442564 Author:coleenp Date: 2016-06-07 15:34 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/60b4f0442564 8158297: Lack of proper checking of non-well formed elements in CONSTANT_Utf8_info's structure Summary: Disallow // in class file names during parsing and throw ClassNotFoundException Reviewed-by: sspitsyn, rehn, gtriantafill ! src/share/vm/classfile/classFileParser.cpp + test/runtime/classFileParserBug/TestBadClassName.java + test/runtime/classFileParserBug/UseBadInterface1.jcod + test/runtime/classFileParserBug/UseBadInterface2.jcod + test/runtime/classFileParserBug/p1/BadInterface1.jcod + test/runtime/classFileParserBug/p1/BadInterface2.jcod Changeset: a1dc09350fbc Author:stefank Date: 2016-06-08 11:15 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a1dc09350fbc 8155638: Resource allocated BitMaps are often cleared twice Reviewed-by: neliasso, kvn ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_ValueSet.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/compiler/methodLiveness.cpp ! src/share/vm/utilities/bitMap.hpp ! src/share/vm/utilities/bitMap.inline.hpp Changeset: 20ab4806c30e Author:sjohanss Date: 2016-06-08 16:29 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/20ab4806c30e 8149085: IntegrationTest1.java fails intermittently due to use of semi-initialized TLAB Reviewed-by: ehelin, mgerdin ! src/share/vm/gc/shared/threadLocalAllocBuffer.hpp ! src/share/vm/runtime/thread.inline.hpp Changeset: b4d82f455636 Author:goetz Date: 2016-06-07 16:08 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b4d82f455636 8158929: [TESTBUG] CommitOverlappingRegions.java can not deal with pages > 32K Reviewed-by: m
Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes
Alan Bateman wrote: On 09/07/2016 09:57, Simon Nash wrote: Is it really a good idea to encourage packages that currently use reflection to access non-exported private fields (an official part of the Java API) to change to using internal APIs? This seems like a step backwards to me. I didn't suggest that. I was just pointing out that some of the 3rd party serialization libraries that we've come across are based on Unsafe and ReflectionFactory and the latter is specifically on critical internal API for that reason. -Alan Yes, I understand. My point was that these APIs might in some cases become a substitute for reflective access to non-exported private fields if the latter is prohibited, Simon
Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes
The argument I'm making is not just someone really wants to do this, but that many people won't settle without it. Reflection has always been the tool to dynamically achieve what the Java language can't always express statically. IoC is built on the notion that language boundaries can and should be broken to achieve magic-like behavior like injecting. Look all over the EE spec and see how injection doesn't care what visibility modifier you use... private methods and private fields are just as readable and writable like public counterparts. Nothing wrong here, nothing broken either. The whole notion that people would turn to Containers to jailbreak a feature smells of a poor design. I'd say it's analogous to how many developers abandoned EJB 2 for Spring until EJB 3 spec leads finally acknowledged what developers really wanted. I think the reaction to this restriction is, in my opinion, going to lead to similar behavior of a mass hunt and development for a better solution. I really don't want to turn to Containers to escape this restriction. I prefer the JDK correctly solve it using the Security Manager to prevent an incongruous solution with the past. To be congruent should be about how the Security Manager can be finely turned to restrict reflection on non-exported types. Oracle can use it to protect JDK internals (if Oracle wants to), but the world can go on doing the reflection it depends on now without more (module) configuration I prefer less configuration, and more convention, unless I have a security reason not to. And what about non-EE containers using injection? I suppose they will need a custom framework to make everything reflectable -- maybe Spring will help out here to universalize a solution? I don't know. But I do know I don't like controlling how reflection acts through a module descriptor. That's clearly a responsibility of the Security Manager and this kind of external control should continue to be built upon. On Jul 9, 2016 3:01 AM, "Alan Bateman" wrote: On 08/07/2016 22:42, Paul Benedict wrote: : > > > 2) Allow layers to control if non-exported types can be reflected. Perhaps > the JDK sets its own layers to "false", but Containers and what they deploy > can be separately configured, each. > > > A container or anything else doing dynamic configuration today provides the module finders and so gets an opportunity to re-write module descriptors if it really wants to. So if someone really wants every module in the configuration to export every package then it is possible. It's a bit of effort of course but it seems better than introducting inconsistencies into how core reflection does access checks vs. the VM and method handles. -Alan
Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes
Paul Benedict wrote: For those who are still supporters of preventing non-exported types from being reflected, I think a compromise can still be found, but it's not in this proposal. Here are two other alternatives I hope the EG will consider: 1) Introduce a new permission type to allow non-exported types to be reflected. I don't find it acceptable the module gets to dictate what can't be reflected. I believe this should be controlled and configured externally -- certainly not the module itself. 2) Allow layers to control if non-exported types can be reflected. Perhaps the JDK sets its own layers to "false", but Containers and what they deploy can be separately configured, each. For example, maybe WebLogic won't allow itself to have its non-exported types reflected, but if each EAR gets its own layers, I could configure WebLogic to allow me to reflect everything within the EAR. PS: I don't see #1 and #2 to be mutually exclusive. Cheers, Paul I would like to propose another possible compromise that might satisfy both of the following requirements that have been expressed on this thread: 1) My module should completely encapsulate some internal classes and make them invisible to the outside world 2) My module or library needs reflective access to internal classes in other modules in order to function correctly At present, a module can mark its packages as: exported at compile time and runtime exported only at runtime via reflection never exported (the default) Instead, these options could change to: exported at compile time and runtime exported at runtime only via reflection (the default) never exported (hidden) This would allow modules to mark certain packages as "hidden" if these packages contain internal methods or fields that should be never be accessible externally under any circumstances. The default would be to allow reflection by other modules or libraries that need such access. Simon
Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes
On 09/07/2016 21:28, Paul Benedict wrote: The argument I'm making is not just someone really wants to do this, but that many people won't settle without it. Reflection has always been the tool to dynamically achieve what the Java language can't always express statically. IoC is built on the notion that language boundaries can and should be broken to achieve magic-like behavior like injecting. Look all over the EE spec and see how injection doesn't care what visibility modifier you use... private methods and private fields are just as readable and writable like public counterparts. Nothing wrong here, nothing broken either. Hence the `exports dynamic` proposal. There is a lot of confusion in this thread and it might be useful if someone could try out a scenario with an injectable constructor or method on a type in an otherwise non-exported package. That might help get the discussion back on track and get on to discussions or proposals on usability (for example). -Alan.
Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes
Alan, but that is extra configuration in the module, as I have pointed out. The whole idea I have to opt someone into fuller reflection is taking control too far. I'm also advocating this is not the responsibility of the module to control reflection. What I have proposed using the Security Manager allows people to restrict the runtime if they do so desire and allow reflection to continue unhindered as-is otherwise. Trying out "dynamic" doesn't address the design except confirming it works according to your intent. I'm complaining (respectfully) about the intent and the restriction as the default behavior. On Jul 9, 2016 4:22 PM, "Alan Bateman" wrote: > On 09/07/2016 21:28, Paul Benedict wrote: > > The argument I'm making is not just someone really wants to do this, but >> that many people won't settle without it. Reflection has always been the >> tool to dynamically achieve what the Java language can't always express >> statically. IoC is built on the notion that language boundaries can and >> should be broken to achieve magic-like behavior like injecting. Look all >> over the EE spec and see how injection doesn't care what visibility >> modifier you use... private methods and private fields are just as readable >> and writable like public counterparts. Nothing wrong here, nothing broken >> either. >> >> Hence the `exports dynamic` proposal. There is a lot of confusion in this > thread and it might be useful if someone could try out a scenario with an > injectable constructor or method on a type in an otherwise non-exported > package. That might help get the discussion back on track and get on to > discussions or proposals on usability (for example). > > -Alan. >