It has nothing to do with Oracle's response -- the Java sandbox is simply broken, and has been known to be broken for at least the last 5 years. There's no fixing it, the approach is fundamentally flawed and fundamental to Java.

This doesn't mean that Java for client-side applications is broken, as long as you don't rely on web based distribution and browser sandboxing.

Can you elaborate on "the approach is fundamentally flawed"?

Don't we rely on a similar sort of sandboxing for Javascript in the browser?

java sandbox has a massive surface area. conceivably any class in the jre could create a hole in the sandbox. modern browser sandboxes appear to be stronger because they rely on an unprivileged process which communicates with a broker interface. the broker code is much smaller than the jre code so it is easier to verify. however, there has been sandbox bypasses. the adobe sandbox bypass was a bug in the broker interface and it can be possible to use local kernel exploits to bypass the sandbox as well.

"This doesn't mean that Java for client-side applications is broken[...]"

I don't know. Java on the desktop requires administrator privileges to be able to notify me that an update is available. Also, it tries to install a virus in the form of "Ask toolbar" every frigging time.

Try installing using http://ninite.com, and use msconfig to make sure "Java Platform Auto Updater" is disabled from your startup.

Oh you don't know my misery : (

I'm actually working on a desktop app used by hundreds of people (and installed by thousands) and my entire business model is being an ISV: trying to sell that Java app to people.

The less Java installed, the harder my life becomes ; (

Are there JREs which you can secretly include in your package, so that it looks like a few-hundred MB native application which happens to be implemented in Java?