RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop
philip.race at oracle.com
Wed May 9 14:42:33 UTC 2018
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.
On 5/9/18, 5:28 AM, Kevin Rushforth wrote:
> The following can also be abstract:
> getComponent, createDragGestureRecognizer, createDragSourceContextPeer
> getTargetActions, getDropTarget, getTransferDataFlavors,
> getTransferable, isTransferableJVMLocal
> 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
>> 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
>>>> This looks okay to me.
More information about the openjfx-dev