<AWT Dev> [9] Review Request: 8074763 Remove API references to java.awt.dnd.peer

[Kevin Rushforth]

Hi Anton,

Yes, there are concerns regarding this, mainly due to the timing and 
build issues. After this week we are no longer auto-syncing changes from 
8u-dev into 9, so we are at a good point to do this, but it will need to 
be done carefully. I expect that we will need at least 2 weeks to switch 
our Hudson build systems to build FX 9 with JDK 9 (we currently build 
with JDK 8), so we will need to coordinate this.

-- Kevin


Anton V. Tarasov wrote:
> Hi Sergey, Kevin,
>
> This method is called from JFX/interop:
>
> DropTargetContext.java
> -    public void addNotify(DropTargetContextPeer dtcp) {
>
> An accessor is introduced. So, we will have to pick it up in 
> JFX/interop once the fix is in the ws.
>
> This means we won't be able to run jfx9 atop of jdk8.
>
> @Kevin,
>
> Do you have any concerns with regard to this fact?
>
> Thanks,
> Anton.
>
> On 25.03.2015 17:35, Sergey Bylokhov wrote:
>> Hello,
>> Please review an updated version of the fix.
>> http://cr.openjdk.java.net/~serb/8074763/webrev.02
>>
>> DropTargetContext.addNotify/removeNotify were renamed and access was 
>> changed to a package private. A necessary methods were added to the  
>> AWTAccessor.
>>
>>
>> 18.03.15 23:47, Phil Race wrote:
>>> I think its preferable to remove (hide) the method rather than leave 
>>> one that
>>> no application code can (or should) call because they can't provide 
>>> a parameter
>>> of the required type.
>>>
>>> -phil.
>>>
>>>
>>> On 03/18/2015 09:24 AM, Sergey Bylokhov wrote:
>>>> Hi, Anton.
>>>> The problem is that this method is called when the peer itself 
>>>> change the information in the DropTargetContext. So this method 
>>>> works like a setter. I can make this method private, and get an 
>>>> access to it via accessor. Will it be better?
>>>>
>>>> 18.03.15 8:27, Anton V. Tarasov wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> The only dependency on JFX/interop is this method in 
>>>>> DropTargetContext.java:
>>>>>
>>>>> 98     public void addNotify(final Object dtcp) throws 
>>>>> IllegalArgumentException {
>>>>>
>>>>> Was that the reason why you left the parameter?
>>>>> Is it technically possible to retrieve the peer via the 
>>>>> ComponentAccessor.getPeer(component) method where the component is 
>>>>> dropTarget.getComponent()?
>>>>>
>>>>> Thanks,
>>>>> Anton.
>>>>>
>>>>> On 16.03.2015 21:30, Sergey Bylokhov wrote:
>>>>>> Hello.
>>>>>> Please review the fix for jdk 9.
>>>>>> There are a number of public API which reference the unsupported 
>>>>>> java.awt. dnd.peer interfaces.
>>>>>>
>>>>>> protected 
>>>>>> java.awt.dnd.DragSource.createDragSourceContext(java.awt.dnd.peer.DragSourceContextPeer, 
>>>>>> ...)
>>>>>> public 
>>>>>> java.awt.dnd.DragSourceContext(java.awt.dnd.peer.DragSourceContextPeer, 
>>>>>> ...) constructor
>>>>>> public java.awt.dnd.DropTarget.addNotify(ComponentPeer peer) and 
>>>>>> removeNotify(ComponentPeer peer)
>>>>>> public 
>>>>>> java.awt.dnd.DropTargetContext.addNotify(DropTargetContextPeer dtcp)
>>>>>>
>>>>>> There is a decision to remove these references as described: 
>>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2015-February/008924.html 
>>>>>>
>>>>>> Changes description:
>>>>>>
>>>>>>     * DragSource.java, DragSourceContext.java, DropTarget.java :
>>>>>>       In all of these methods the peers are used as a parameters.
>>>>>>       In most of the cases these parameters are not necessary,
>>>>>>       because the peer can be accessed using the reference to the
>>>>>>       shared object(Component/DropTarget etc). Since these
>>>>>>       methods can be useful I did not remove them, but remove one
>>>>>>       parameter only.
>>>>>>     * DropTargetContext.java: addNotify() is called when we
>>>>>>       cannot get the information about a peer so I change type of
>>>>>>       the parameter and documentation of the method. It seems
>>>>>>       that these methods DropTargetContext.addNotify/removeNotify
>>>>>>       are not useful and I can change them by private version,
>>>>>>       but I don't know which way will be better.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074763
>>>>>> Webrev can be found at: 
>>>>>> http://cr.openjdk.java.net/~serb/8074763/webrev.01
>>>>>>
>>>>>> -- 
>>>>>> Best regards, Sergey.
>>>>>>
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Best regards, Sergey. 
>>>
>>
>>
>> -- 
>> Best regards, Sergey. 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20150330/28fe3230/attachment.html>