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

[Philip Race]

Yes, they (the methods mentioning Peer) should be renamed.

Qn. to Mandy & Alan : it seems there is no need to mention this module
in make/common/Modules.gmk in order to get it built, but is there any
advantage in doing so ? I mean without it, there is no conscious listing of
it as a module nor classification of it.

Another thing that Kevin & I touched on in conversation is that it seems
doclint fail on warning must be disabled by default .. and I suppose that
is what we want here since documentation is minimal.

-phil.

On 5/9/18, 5:28 AM, 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
>>>
>>
>