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

Erik Joelsson erik.joelsson at oracle.com
Tue Jan 13 12:57:20 UTC 2015


The makefile change looks good to me.

/Erik

On 2015-01-13 12:40, Sergey Bylokhov wrote:
> Hi, Alan.
> On 12.01.2015 23:42, Alan Bateman wrote:
>> Thanks for doing this. I think it looks okay except for modules.xml 
>> where it looks like there may be a few issues.
>>
>> 1. You've updated the definition of java.corba to depend on 
>> java.datatransfer but I don't think this is needed (is there code in 
>> java.corba that uses this API?).
>>
>> 2. Same thing needs to be checked in java.xml.bind, jdk.jconsole and 
>> jdk.runtime where it's not clear to me that code in these modules 
>> uses this API.
>
> java.datatransfer was removed everywhere except:
>
> 1. 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 {
>
> 2. java.xml.soap
> jaxws/src/java.xml.soap/share/classes/com/sun/xml/internal/messaging/saaj/soap/FastInfosetDataContentHandler.java:53: 
> error: cannot find symbol
>     public DataFlavor[] getTransferDataFlavors() { // throws Exceptio
>
> 3. java.xml.ws
> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/developer/StreamingDataHandler.java:51: 
> error: cannot access Transferable
> public abstract class StreamingDataHandler extends 
> com.sun.xml.internal.org.jvnet.staxex.StreamingDataHandler {
>
> The new versions:
> http://cr.openjdk.java.net/~serb/8056298/webrev.02/jdk
> http://cr.openjdk.java.net/~serb/8056298/webrev.02/root
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8056298
>
>>
>> 2. The update to java.activation to depend on java.datatransfer looks 
>> right but shouldn't you drop the dependency on java.desktop?
>>
>> I don't have any other comments except to mention that java.xml.soap 
>> has been subsumed into java.xml.ws. Those changes are in jdk9/dev and 
>> it looks like jdk9/client might be a bit out of date.
>>
>> -Alan
>>
>
>




More information about the build-dev mailing list