A plugin would be great, if it had JRE to fall back on.
I would love it and really believe that it is doable, but unfortunatly it is only interresting if you can reach at least something like 50% of market place wich will probably requiere huge money to be competitive against flash/java : advertisments / contract with major : MS / mozilla / google / apple (NB: a contract/accord with MS will be far a sufficient start …), or requiere an excellent idea that would make people think that it is a requiered/needed plugin (as flash)
but sure with a cupple of volunters we could have done better plugin (including plugin release update & managment) then what Sun did for last ten years… IMHO : Sun try to go too fast and do not finish/fix current issue, dont take care of existing works, release update at a too high frequency
is that possible? cause if so, then ppl dont HAVE to get it, just only if they want something better
I dont see why not, if you had something like:
<jgo width="100%" height="90%" code="MainApplet" archive="unsigned.jar, signed.jar">
<param name="separate_jvm" value="true">
<applet width="100%" height="90%" code="MainApplet" archive="unsigned.jar, signed.jar">
<param name="separate_jvm" value="true">
<p ALIGN=center>You need the JGO Plug... click here link blah blah blah</p>
</applet>
</jgo>
Im assuming that the plugin would work in its own vm. or rather in a seperate vm for each instance. It should work after installing, without restart of browser.
Would be a big task though, what to include, and what to strip back on. Kaffe might be a good starting place as the plugin is only needed for applets.
there would be a few core security issues to work through im sure.
anyway just some ideas. I would be willing to invest a decent chunk of time into a project like this
edit: mac wouldnt be a problem as it uses its own VM, that doesnt give such ugly restrictions
one possible solution may be to do … but sooo boring…
myUnignedApplet.html
<APPLET archive="unsigned.jar" MAYSCRIPT></APPLET>
mySignedApplet.html
<APPLET archive="signed.jar" MAYSCRIPT></APPLET>
when requiere secured privilege from myUnignedApplet.html:
this.getAppletContext().showDocument("mySignedApplet.html","myHiddenFrame");
and then acces signed applet method via DOM/Javascript
but I dont like it, that’s really not a clean/final solution
Good idea, might work, but it’s a horrible workaround.
I decided to go with a front page without restricted needs. then when it requires permissions, it opens up another URL on “_self” and passes information via a URL query string.
They might have fixed some of the things that were broken in u19
http://java.sun.com/javase/6/webnotes/6u20.html#otherbugfixes-6u20
I’m not sure though as the bug descriptions don’t display correctly.
Awesome stuff, they apparently don’t even test the update announcements!
nope unfortunetly they haven’t, u20 was simply rushed out to fix the jws exploit that was giving java/oracle bad press on almost all the tech sites.
I didn’t install u19, I just installed u20 and neither my webstart app (uses LWJGL) or jinput applet present any extra warning dialogs. They are unchanged so as they were before this sorry mess started.
HTH
Endolf
Too early to say. Apple’s Java version always lags behind Sun’s, it’s currently at 1.6.0_17. Who knows what will happen in the next release? 
I found a workaround to delay the security dialog, using two applets: one signed and one unsigned.
This is the HTML with the two applets (the signed applet is commented out):
<html>
<head>
<script type='text/javascript'>
function openSignedApplet()
{
var holder = document.getElementById('signed_holder');
var html = holder.innerHTML; // strip comments
var off = html.indexOf('<applet');
var end = html.indexOf('</applet>')+9;
holder.innerHTML = html.substring(off, end); // activate signed applet
}
</script>
</head>
<body>
<div id='unsigned_holder'>
<applet name="unsigned"
code="MixedUnsignedApplet.class"
archive="/unsigned.jar"
width="512" height="64">
</applet>
</div>
<hr>
<div id='signed_holder'>
<!--
<applet name="signed"
code="MixedSignedApplet.class"
archive="signed.jar"
width="512" height="64">
</applet>
-->
</div>
</body>
</html>
This code is used by both applets to find eachother:
public class MixedAppletCommunication
{
public static Applet waitForCompanion(Applet self)
{
while (true)
{
Applet applet = getCompanion(self);
if (applet != null)
{
return applet;
}
Thread.sleep(100L);
}
}
public static Applet getCompanion(Applet self)
{
Enumeration<Applet> applets = self.getAppletContext().getApplets();
while (applets.hasMoreElements())
{
Applet applet = applets.nextElement();
if (applet == null)
{
// being paranoid
continue;
}
if (applet == self)
{
// found own applet instance
continue;
}
if (applet.getClass().getName().equals(self.getClass().getName()))
{
// webpage was refreshed, the previous applet is still around
continue;
}
// found companion
return applet;
}
// failed to find companion
return null;
}
}
The unsigned applet activates (uncomments) the signed applet using:
AppletPluginUtil.evalJavascript(unsignedApplet, "openSignedApplet();");
public class AppletPluginUtil
{
public static Object evalJavascript(Applet applet, String script) throws IllegalStateException
{
try
{
// JSObject.getWindow(applet).eval(script);
Class< ? > clazz = Class.forName("netscape.javascript.JSObject");
Object jsObject = clazz.getMethod("getWindow", Applet.class).invoke(null, applet);
Method jsEval = clazz.getMethod("eval", String.class);
return jsEval.invoke(jsObject, script);
}
catch (Exception exc)
{
throw new IllegalStateException(script, exc);
}
}
}
Both applets are in seperate classloaders, so AFAIK, the only way to communicate between the applets is to write a protocol around applet.setName() and applet.getName() on both applets. That means all your transfered data must be serialized, converted to a String, and passed to the other applet using applet.setName(String); At the moment I’m sending byte[]s back and forth, as char[]s, with two bytes per char (no encoding), which is fast. You can hook into the setName() call using applet.addPropertyChangeListener(“name”, listener), so that you don’t have to poll getName() for updates.
I implemented this, and I can, using rather highlevel code, request a FileInputStream in the unsigned applet, pass the request to the signed applet, create it and pump it through getName()/setName() in both applets, and reconstruct an InputStream in the unsigned applet, which can be read like any other stream.
// ensure the signed applet is active (and activated only once)
AppletPluginUtil.evalJavascript(unsignedApplet, "openSignedApplet();");
InputStream in = unsignedApplet.createRemoteFileInputStream(new File(path));
OutputStream out = unsignedApplet.createRemoteFileOutputStream(new File(path));
Pair<InputStream, OutputStream> socket = unsignedApplet.createRemoteSocketStreams(host, port);
Genius! Do you think they’ll classify this as a security threat and make another dysfunctional update?
Riven strikes again.
As fas as being a security risk I personally doubt it, as it still would require signing of the applet to get secure access.
That’s the same with any signed/unsigned code, and Oracle crippled exactly that.
Besides that, I have another slower solution (inefficiently bruteforcing ‘something’ at max 8MB/sec), which, for the sake of making sure it won’t get crippled, I keep a secret… :persecutioncomplex: also, we can always communicate through javascript.