On 1/13/15 9:34 AM, Sergey Bylokhov wrote:
On 13.01.2015 20:26, Mandy Chung wrote:
On 1/13/15 7:45 AM, Sergey Bylokhov wrote:
On 13.01.2015 17:23, Alan Bateman wrote:
Typo in my mail, I meant verify-modules.
They are currently issues with verify-modules and boot cycle builds
so I think verify-modules is currently disabled (at least in
jdk9/dev). Erik is working on this via JDK-8067479.
The new versions:
http://cr.openjdk.java.net/~serb/8056298/webrev.04/jdk
http://cr.openjdk.java.net/~serb/8056298/webrev.04/root
- sun.reflect.misc and sun.security.util were exported to
java.datatransfer.
- jdk.hotspot.agent now depends on java.datatransfer
"make verify-modules" was completed w/o issues.
Thanks for doing this. java.activation, java.xml.ws, jdk.hotspot.agent
uses java.awt.datatransfer. I don't find java.xml.bind using it.
$ jdeps -p java.awt.datatransfer $BUILD_OUTPUTDIR/jdk/modules/*
The result shows that java.activation, java.xml.ws, jdk.hotspot.agent
uses java.awt.datatransfer (there is a bug in jdeps that didn't show
the module name correctly - will file a bug and fix it).
How do you find java.xml.bind depend on java.datatransfer? You can
run this from your build:
$ jdk/bin/jdeps -s jdk/modules/java.xml.bind/
it does not compile w/o it:
java.xml.bind:
jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/staxex/StreamingDataHandler.java:53:
error: cannot access Transferable
public abstract class StreamingDataHandler extends DataHandler
implements Closeable {
I see. java.xml.bind -> java.desktop is temporarily needed until the
module system is in replace unless the build adds the re-exported module
(i.e. java.datatransfer) to the sourcepath to compile java.xml.bind.
That change is fine.
About the qualified exports from java.base:
java.awt.datatransfer.DataFlavor uses
sun.security.util.SecurityConstants.GET_CLASSLOADER_PERMISSION
I suggest to remove this dependency by creating the instance
when security manager is on:
new RuntimePermission("getClassLoader")
is it necessary? I prefer to use current solution as more readable.
I'd like to keep the qualified exports to the ones which are absolutely
needed. Sharing common code is good while this "getClassLoader"
permission is part of the specification and allowing desktop to access
the entire sun.security.util package is more than it needs
(java.datatransfer only depends on this static instance). The cost of
creating a Permission object is low and only when security manager is
on. I would recommend to replace the dependency on SecurityConstants.
Mandy
