JDK-8061315 : [JFXPanel, Mac] need an ability to check if Clipboard has been changed from outside of Swing/AWT
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 8u20
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • OS: os_x
  • Submitted: 2014-10-17
  • Updated: 2015-03-30
  • Resolved: 2015-03-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Related Reports
Duplicate :  

The FX issue above is caused by the fact that on OSX, when Clipboard is modified not in Swing, the notification of the change is only triggered by re-activating of the Swing toplevel, assuming that any outside change could only happen outside of the Swing toplevel. However, this is not the case for JFXPanel, where Clipboard is modified without switching the activation. As a result, data copied to Clipboard from FX couldn't then be pasted to Swing in case Clipboard had contained some Swing data prior to that. Because nothing notifies it of the change, so it uses a cached content (on the java level).

(Note that FX and Swing has different Java clipboard implementations, but they share the system one.)
The issue is resolved with JDK-8071668.

CClipboard contains a package private checkPasteboard() method which does what we need - it checks if the system pasteboard has been modified (externally) and notifies SunClipboard in case it has. The latter calls for lostOwnershipImpl() which resets the content. When Clipboard is then asked for the content it will read it from the native peer which will provide up-to-date data. I'm suggesting a fix which adds a new internal public method to access the mentioned functionality. (I left the Win/Lin peer methods unimplemented, assuming they should be no op). webrev: http://cr.openjdk.java.net/~ant/JDK-8061315/webrev.0