copy/paste : Java Glossary

In most Windows apps, you can copy a snippet of selected text to the clipboard with Ctrl-C. You can then paste it somewhere else with Ctrl-V. You can copy and delete in one operation with Ctrl-X. Java AWT (Advanced Windowing Toolkit) apps and Applets support copy/paste without writing any code, as do Java Swing apps.

Ostensibly to close security holes, As of JDK (Java Development Kit) 1.6.0_24, Java Swing JApplets do not support copy/paste, (Ctrl-C/Ctrl-V in Windows) unless you sign the Applet.

You can access the clipboard as a whole in signed Swing JApplets using code similar to this ClipboardPoker code part of the common18 package.

Making Ctrl-C/Ctrl-V Work Again

What can you do to make ordinary Ctrl-C/Ctrl-V work with unsigned Swing Applets in JDK 1.6.0_24+?

• Capitulate. If you are the author, buy a certificate and sign the Applet, with the side effect of inconveniencing and frightening your users needlessly.
• Modify the java.policy file for all users:
• Tell users to use an old version of Java.
• In Firefox, if you don’t wait for the page to completely load (including Google ads, translate, other ads etc), Ctrl-C/Ctrl-V won’t work. This has nothing to do with Java. All you can do is wait for the page to completely load before typing, or complain to the Firefox developers.

Why did Oracle do this?

Here is my speculation: Ctrl-C and Ctrl-V should be completely safe. The program cannot use them to sneakily peek at the clipboard without the user knowing. They are handled without application program involvement. However, Copy/Paste menu buttons can, since the program intervenes and can trigger the same actions even without user input. It could be handled two ways. Let Ctrl-C and Ctrl-V work always and the buttons only work when signed, or they could have everything work only when signed. Oracle chose consistency over convenience.