Java 1.6.0_24 Breaks Collaboration Server Bulk Upload

If you, like me, were foolish enough to upgrade your Java Runtime Environment to 1.6.0_24 (I mean, REALLY, who DOES THAT!?), then you’ve likely found that Bulk Upload (and possibly WebEdit) no longer work in WCI Collaboration Server.

Why?  This post by gimble2 about sums it up:

Java is under new management. Sun was very strict in keeping backwards compatibility; I wouldn’t be surprised if Oracle takes the policy of security first, compatibility second.

Indeed, this is a big problem because Java 1.6.0_24 lies to users:

Unrestricted Access, huh? Bullsh*t.

You can confirm this by viewing the Java Console when trying to run Bulk Upload:

There you’ll likely see an exception like this:

Java Plug-in 1.6.0_24
Using JRE version 1.6.0_24-b07 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\Administrator
Exception in thread “Basic L&F File Loading Thread” access denied ( C:\Documents and Settings\Administrator\My Documents read)
at Source)
Exception occurred during event dispatching: access denied ( C:\Documents and Settings\Administrator\My Documents read)
at Source)
at bulkupload.BulkUploadApplet. chooseFiles(
at bulkupload.BulkUploadApplet. access$100(
at bulkupload.BulkUploadApplet$ (

at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$000(Unknown Source)
at java.awt.EventQueue$ Source)
at java.awt.EventQueue$ Source)
at Method)
at$1. doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at Source)

The easiest fix for this isn’t even something you’ll be able to get your end users to do:
Edit your \%JRE_HOME%\lib\security\java.policy file. Inside of the “grant” section, add this:

grant {

This basically says that the Java client will actually allow full access to the file system for file browsing and uploading.

Of course, astute readers will note that this is a client-side change, and therefore will be very difficult to deploy in your enterprise – or, worse, to all clients on your extranet. Your best bet, as far as I can tell, is to have your users not update Java to the latest version.

I’m open to suggestions here – any ideas on how to overcome this dramatic security change in Java with remotely deployed policy files, or a server-side policy configuration file?

UPDATE 3/24/2011: I can now confirm this used to work (by Sun / Oracle’s own documentation, and this reference in Wikipedia). Basically those articles say that if an applet is signed, and the user approves it to have access (see above screen shot), then it should have unrestricted access to the system. There are now two bugs created in Oracle’s Sun Developer Network. Now that Oracle owns Sun, and by extension, Java, how many more bugs can we expect as applet developers worldwide struggle to explain to their users: “It’s not the my fault – it’s Oracle’s!”?

Ironically, I have to tell my clients: “It’s not the [Plumtree / ALUI] Oracle’s fault – it’s [Sun / Java] Oracle’s!”

Tags: , , , ,

One Response to “Java 1.6.0_24 Breaks Collaboration Server Bulk Upload”

  1. Raed says:

    Thanks Matt, crazy that one needs this workaround. It was very helpful for sure.