[11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

[Kevin Rushforth]

I confirm that this fixes the issue. The interface change to make the 
two static methods e instance methods is a good change in any case.

I am not a Swing "R"eviewer, but the .13 webrev gets a +1 from me.

-- Kevin


On 5/10/2018 8:20 AM, Prasanta Sadhukhan wrote:
>
> Hi Kevin,All,
>
> Please find the modified webrev fixing this #1 issue
> http://cr.openjdk.java.net/~psadhukhan/fxswing.13/
> via change in 
> jdk/swing/interop/DropTargetContextWrapper.java#setDropTargetContext 
> and FXDnD.java#postDropTargetEvent
>
> For me, #2 works, #3 doesn't work even now due to JDK-8141391 
> <https://bugs.openjdk.java.net/browse/JDK-8141391> and #4 works for me.
>
> Regards
> Prasanta
> On 5/9/2018 11:29 PM, Kevin Rushforth wrote:
>> Hi Prasanta,
>>
>> The API looks good now.
>>
>> All of our automated tests work (except for the ones with a security 
>> manager due to JDK-8202451 
>> <https://bugs.openjdk.java.net/browse/JDK-8202451>).
>>
>> The only functional problem that I see is that Drag and Drop onto a 
>> SwingNode doesn't work. We need to make sure that we test the 
>> following four cases:
>>
>> 1. Drag / drop onto a Swing component in a SwingNode
>> 2. Drag / drop from a Swing component in a SwingNode
>> 3. Drag / drop onto a JavaFX control in a JFXPanel
>> 4. Drag / drop from a JavaFX control in a JFXPanel
>>
>> So far I only tried the first one; the others still need to be validated.
>>
>> -- Kevin
>>
>>
>>
>> On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote:
>>> Modified webrev to cater to this
>>>
>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.12/
>>>
>>> Regards
>>> Prasanta
>>> On 5/9/2018 5:58 PM, Kevin Rushforth wrote:
>>>> The following can also be abstract:
>>>>
>>>> LightweightContentWrapper:
>>>>   getComponent, createDragGestureRecognizer, 
>>>> createDragSourceContextPeer
>>>>
>>>> DropTargetContextWrapper:
>>>>   getTargetActions, getDropTarget, getTransferDataFlavors, 
>>>> getTransferable, isTransferableJVMLocal
>>>>
>>>> DispatcherWrapper:
>>>>   isDispatchThread, createSecondaryLoop
>>>>
>>>> The rest looks good to me (although I still see two public methods 
>>>> with "Peer" in the name, so Phil may want those renamed).
>>>>
>>>> -- Kevin
>>>>
>>>>
>>>> On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote:
>>>>> Modified webrev to cater to these 3 observations
>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.11/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>>
>>>>> On 5/9/2018 5:03 AM, Kevin Rushforth wrote:
>>>>>> The module definition for jdk.unsupported.desktop and the changes 
>>>>>> to java.desktop look fine.
>>>>>>
>>>>>> In reviewing the jdk.swing.interop API, I have the following 
>>>>>> suggestions / observations:
>>>>>>
>>>>>> 1. DispatcherWrapper, DragSourceContextWrapper, 
>>>>>> DropTargetContextWrapper, and LightweightContentWrapper can all 
>>>>>> be abstract, along with most of the methods (rather than having 
>>>>>> an empty body return value that is never used).
>>>>>>
>>>>>> 2. The addNotify method in LightweightFrameWrapper is unused. 
>>>>>> Should be used somewhere? If not, then it can be removed.
>>>>>>
>>>>>> The implementation of the new wrapper classes looks OK to me with 
>>>>>> one observation that might or might not matter:
>>>>>>
>>>>>> 3. The behavior of getDefaultScaleX/Y (which is now in 
>>>>>> SwingInteropUtils) has changed in the case where the Graphics is 
>>>>>> not an instance of SunGraphics2D. The former behavior was to 
>>>>>> leave the instance variables X and Y unchanged. The new behavior 
>>>>>> will set them back to 1.0. Maybe this can't happen in practice, 
>>>>>> but it is something to consider.
>>>>>>
>>>>>> -- Kevin
>>>>>>
>>>>>>
>>>>>> On 5/8/2018 3:31 AM, Alan Bateman wrote:
>>>>>>> On 08/05/2018 06:51, Prasanta Sadhukhan wrote:
>>>>>>>> Modified webrev to rename to InteropProviderImpl
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fxswing.10/
>>>>>>> This looks okay to me.
>>>>>>>
>>>>>>> -Alan
>>>>>>
>>>>>
>>>>
>>>
>>
>