[9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module

[Mandy Chung]

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