and finally yes signed/unsigned does not work anymore ( after 3 years of using it... this is just ununderstandable & STUPID ! ) and always show a security dialog... bravo... clap clap to Sun

Actually, if you add "Trusted-Library: true" to the manifest, it does not immediately show the security dialog, but... once it does, it either hangs or Class.forName("some.secure.package.SecureClass") throws a ClassNotFoundException, because the classloaders are strictly separated.

There must be a way...

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Actually, if you add "Trusted-Library: true" to the manifest, it does not immediately show the security dialog, but... once it does, it either hangs or Class.forName("some.secure.package.SecureClass") throws a ClassNotFoundException, because the classloaders are strictly separated.

There must be a way...

thanks, I am looking on this solution right now, I hope it will do the trick... at least until the 1.6-20 release get out ....

LWJGL AppletLoader also broke due to this sudden update and change on how classloaders work with mixed signed/unsigned jars. However its fixed now and LWJGL 2.4 should be out soon.

Anyway since the loader shows the security dialog at initialisation its easy to work round any later issues due to the extra permissions, what you guys are trying to do is gonna be pretty tricky now due to the changes (i.e. get security dialog to show from an unsigned jar).

LWJGL AppletLoader also broke due to this sudden update and change on how classloaders work with mixed signed/unsigned jars. However its fixed now and LWJGL 2.4 should be out soon.

nice to know you manage to fix it for LWJGL, but does it apply for people having made Applet with older LWJGL ?

as a side note: 3DzzD Applets still works too ( either you press yes or no they will work ) but the problem, what make me angry is that you now get a scary popup at startup ... how Sun can made such fundamental change !?

nice to know you manage to fix it for LWJGL, but does it apply for people having made Applet with older LWJGL ?

only effects ppl using an older LWJGL who were using a mix of signed and unsigned jars (by that I mean only the lwjgl_util_applet.jar and lzma.jar), shouldn't effect those that were signed all the jars.

I had all jars signed with the same certificate and it still happened to me. I think the reason was that some of the jars were also lzma compressed, causing java to consider them to be unsigned binary files.

Adding "Trusted-Library: true" to the manifest in the two jars directly loaded by java made all the problems go away.

I really cant understand how and who validate such change in the plugin... this seems so stupid & risky...

1 - it is incompatible with old Applet and make severals of them crash or display scary & confusing popup2 - it DOES NOT make anything more secure and then it is only a useless & regressive change : I think about that using liveconnect, untrusted code can still command trusted code (via delayed or not javascript) without any warning but this is just more boring & complicated to do this way for real world project and so profesional wont use this way but hackers will ... so it make real company work lot more complicate while it does not make hackers life harder...

hmm, going the custom plugin route would be cool as it'd give us complete control over how the plugin works, runs and would finally give us a chance to get it right (something that Sun/Oracle have failed at for the last decade)

However going the custom plugin route is IMO a rather difficult task, especially as you'd have to get it right on all the platforms + different browsers. It'd also require doing C/C++ combined with Java (jni?) which is always a pain.

Also ppl don't like installing plugins, just take the example of Unity3D, that is one plugin that IMO got almost everything right and nailed the user experience. However many ppl just avoid Unity3d games as they don't want to install yet another plugin.

Its hard to ignore a present user base of about 60% of all computers already having the java plugin.

I think you can still get a decent user experience with the java plugin (provided you jump lots of hoops, bugs, limitations, issues, security dialogs, etc) still IMO easier then going the custom plugin route where its an uphill battle to get users to install it.

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

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

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.

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.

1 2 3 4 5 6

// ensure the signed applet is active (and activated only once)AppletPluginUtil.evalJavascript(unsignedApplet, "openSignedApplet();");

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... also, we can always communicate through javascript.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org