Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Paul Benedict]

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.
>

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Alan Bateman]

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

[Simon Nash]

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

[Paul Benedict]

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

[Simon Nash]

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

hg: jigsaw/jake/hotspot: 159 new changesets

[alan . bateman]

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: 

hg: jigsaw/jake/jdk: 83 new changesets

[alan . bateman]

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
! 

hg: jigsaw/jake/jaxws: 2 new changesets

[alan . bateman]

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

[alan . bateman]

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: 

hg: jigsaw/jake/nashorn: 5 new changesets

[alan . bateman]

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/corba: 2 new changesets

[alan . bateman]

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

[alan . bateman]

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

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Jochen Theodorou]

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

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Alan Bateman]

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

[Simon Nash]

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

[Alan Bateman]

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]

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

[Simon Nash]

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

[Gregg Wonderly]

The practical matter is simply that all of this name visibility business is 
just entirely the wrong thing to be managing “modules” around.  Instead, 
modules should be things that are more easily managed with tools that 
facilitate things that container systems will want to do.   Modularity as a 
design paradigm has nothing to do with namespace visibility.   Packages already 
provide name visibility and separation.  Keywords already provide restricted 
access unless you pry open the door with language features aimed specifically 
at solving the multiuse/reuse problem that public/internal/private restrictions 
create.  

For a long time I’ve set back and watched this project inching along with all 
kinds of people asking all the questions that I thought should be asked about 
why the EG was doing what they were doing.  I am really afraid i still don’t 
know why this hiding game is so interesting and valuable.  Is there really a 
giant problem that a majority of the Java community has now that this is going 
to just solve, and make developing faster and more readily managed?  
Versioning, and dynamic class replacement would be the kind of things that a 
module system could really provide to help software be more resilient to life 
cycle management over time.

We already have things like maven to help with dependency management.

We already have things like spring to help with dependency injection so that 
there are not hard bindings in code against specific versions.

We already have many different container systems that provide many different 
ways to manage software “pieces”.  The problem is that each one of them has a 
different paradigm and framework that one must program against.

Shouldn’t modularity really be about helping target more of those container 
systems implicitly instead of requiring explicit wrapper classes or other 
properties of the build system to make it possible to use the same module in 
multiple environments?

Why is this namespace hiding/exporting so important to Java developers?   Which 
Java developers need that level of isolation and why is it that everyone will 
have to deal with it, if those developers are not 90% of all developers 
benefiting?

Gregg Wonderly

> On Jul 8, 2016, at 4:42 PM, 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
> 
> On Fri, Jul 8, 2016 at 4:16 PM, Jason Greene 
> wrote:
> 
>> 
>> On Jul 7, 2016, at 5:31 PM, Paul Benedict  wrote:
>> 
>> If this restriction stays (and I am really hoping it doesn't), my next
>> best hope is for Containers like WildFly, Tomcat, SpringBoot etc. to enable
>> me to do this. If the Layer has a hook into amending the Module Descriptor,
>> then I am hoping each Container will automatically set "dynamic" to each
>> non-exported package. I think this will be a highly requested and
>> sought-after feature.
>> 
>> 
>> That’s probably something we would do if this notion remains.
>> Unfortunately it means that you would then have different behavior for
>> standalone SE usage and container usage, making it harder to share code. It
>> also might introduce a conflict that wasn’t there before (e.g. split
>> package)
>> 
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>> 
>>