FULL PRODUCT VERSION :
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
Drag-and-drop code that was working fine prior to Java 6 Update 19 started failing with a SecurityException in Java 6 Update 19 and continues to fail in Java 6 Update 20 in Transferable.getTransferData(DataFlavor) in cases where the Transferable was obtained as part of a drag-and-drop operation.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
This bug is reproducible with any drop-target handling code in any applet -- unless the getTransferData() call is wrapped in a PrivilegedAction.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I would expect no such SecurityException as all the Javadoc for getTransferData(), both on Transferable and on DropTargetContext.TransferableProxy fails to mention any possibility of a SecurityException occuring. Moreover all Java Plug-In versions prior to Java 6 Update 19 did not produce a SecurityException in the same circumstances, going all the way back to Java 1.3.
ACTUAL -
The actual result is a SecurityException blocking the drag-and-drop operation from succeeding.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "AWT-EventQueue-2" java.security.AccessControlException: access denied (java.awt.AWTPermission accessClipboard)
         at java.security.AccessControlContext.checkPermission(Unknown Source)
         at java.security.AccessController.checkPermission(Unknown Source)
         at java.lang.SecurityManager.checkPermission(Unknown Source)
         at java.lang.SecurityManager.checkSystemClipboardAccess(Unknown Source)
         at sun.awt.dnd.SunDropTargetContextPeer.getTransferData(Unknown Source)
         at sun.awt.datatransfer.TransferableProxy.getTransferData(Unknown Source)
         at java.awt.dnd.DropTargetContext$TransferableProxy.getTransferData(Unknown Source)
         ....

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
The only workaround appears to be to wrap the getTransferData() call in a PrivilegedAction and sign the jar in question. I have done this and it works fine. There are issues here, however. Transferable.getTransferData() is a fairly high level API in some respects. One can't really make just the attempt to get transfer data from the native drop peer privileged. Instead one ends up making a lot more than that privileged by wrapping this API in a privileged API block, which is rather unfortunate.

Overall it would appear that this change is an intentional security fix. If so, documentation is needed to show what all changed (was it just this API?) so that developers can work around the issue. Also, if this was intentional, then some clear heads-up that perfectly valid applications are likely to break with this update was clearly needed here -- our customers found this before we did thanks to the lack of adequate notice.

Release Regression From : 6u18
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.