JDK-5076514 : Incompatible change in clipboard handling in swing between b55 and b56
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2004-07-21
  • Updated: 2005-01-15
  • Resolved: 2005-01-15
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.
Other JDK 6
5.0u4Fixed 6 b20Fixed
Description
The Tiger Build 56 replaced the way how Swing components deal with clipboard and this resulted in compatibility problems in NetBeans. Most of them get resolved, thanks to help of Igor Kushnirskiy and NetBeans does not have a problem anymore.

However I'd like to point out an incompatibility in a way how tiger b56 deals with SecurityManager:

In older versions <= b55 it was possible to prevent swing from accessing system clipboard just by overriding SecurityManager.checkSystemClipboardAccess and the swing would silently fallback to use its own clipboard.

This does not work anymore, if used swing will complain by printing an error message to the console (which scares NetBeans users).
Comments
EVALUATION jt97948: I've deleted the old evaluation (thanks for it and all your help) because this is now completely different bug. Assign Prio/Severity as you want, this does not affect NetBeans anymore, as I applied the WorkAround. Now the bug is just about backward compatibility of java. PS: Fell free to delete this comment as well. Name: ik75403 Date: 08/30/2004 >replace calls to > >sm.checkPermition (new AWTPermition ("clipboardAccess"); > >with > >sm.checkSystemClipboardAccess() There is no need to replace. We need to call both. If either throws an exception access is to be rejected ============= *** /tmp/geta8403 Mon Aug 30 16:03:44 2004 --- SwingUtilities2.java Mon Aug 30 16:00:03 2004 *************** *** 718,723 **** --- 718,724 ---- try { sm.checkPermission(SecurityConstants. ACCESS_CLIPBOARD_PERMISSION); + sm.checkSystemClipboardAccess(); canAccess = true; } catch (SecurityException e) { } ============= ====================================================================== It is save to use sm.checkSystemClipboardAccess() if we dealing with incorrect SecurityManager it will fail in many other places. ###@###.### 2004-12-10 00:12:56 GMT
10-12-2004
WORK AROUND The solution is to completely ignore the SecurityManager.checkSystemClipboardAccess (introduced in JDK1.1) and override SecurityManager.checkPermition ("clipboardAccess") which was introduced in JDK1.2. Then everything works as desired. The problem however is that this is not backward compatible. Old SecurityManagers (like our own) written for JDK1.1 expect the old checkSystemClipboardAccess to be called and not the new method.
25-09-2004
SUGGESTED FIX Whenever a code wants to consult a SecurityManager about a check that was available in pre-1.2 days (no Permition framework), it should always call appropriate 1.1 method (and let it to delegate to the checkPermition or call super.checkTheMethodName). So in case of our clipboardAccess problem, replace calls to sm.checkPermition (new AWTPermition ("clipboardAccess"); with sm.checkSystemClipboardAccess()
25-09-2004