We already added the needed Trusted-Library and stuff. Applets all good.

Then I updated the webstart...

*nothing* worked...

Issue 1:Proper signed jar, proper manifest - just wouldn't load. Cause: A Trusted-Only jar cannot be run from "sandbox" mode.Solution: Add <security><all-permissions/></security> even though I DONT NEED it

Issue 3:Proper signed jar, proper manifest, excess security rights, messy resources into jar where I dont want it. Error: NullPointerException when accessing said resources.Cause: My lwjgl_test.jar (in Trusted-Only: true mode) with all my resources could not use the LWJGL util class for loading wave files because that was implemented like this:

and since update 19, the extension and the application jar are no longer running in the same classloader - so there is no resource to be found.Only about everybody is using a syntax similar to the above - including the java tutorials.

Now, security aside - why the HELL did anyone approve this piece of shit update??? Pardon my language but this has got to be the most f* up EVER point release in the history of software updates.

* Matzon shakes fist

EDIT: hang on to issue 3 - may be cause by something else ... investigating .... nope, its valid - fix: switch to context classloader, as per comments

issue 3 also breaks code using things like Class.ForName(String) if the jars get loaded in separate classloaders.

Also what's strange is that under Sun almost every release of Java6N Update had an alpha/beta before a final release, Java6u19 being the first release under Oracle didn't have a public alpha/beta. The update was also pushed straight to the masses via the java auto updater and didn't even get released to developers for a small period so that they could test their apps.

Should work if they've implemented it as expected. There should be a delegating class loader across all the resource/code JARs that can be used to see all of them. In a JEE world you'd expect to see this classloader being passed around on the thread.

Should work if they've implemented it as expected. There should be a delegating class loader across all the resource/code JARs that can be used to see all of them. In a JEE world you'd expect to see this classloader being passed around on the thread.

Should work if they've implemented it as expected. There should be a delegating class loader across all the resource/code JARs that can be used to see all of them. In a JEE world you'd expect to see this classloader being passed around on the thread.

Classloaders don't have to be one big lump. Quite often is useful and more flexibile to be able to load seperate application artifacts in different class loaders to support isolation between artifacts and co-hosting of applications. Seems like this is the case here, each artifact is being loaded in a seperate classloader.

In these cases the context class loader of the thread is normally set to a class loader that gives you the complete context of the application as viewed by the current piece of code. In this case it means that before the webstart client calls main the context class loader "should" (as hackboy rightly points out) be set to a class loader than spans all the others.

Thanks kapta for pointing me in the right direction in the other thread.

When I first started my battle with u19 (from HELL!), my applets didn't start anymore AT ALL. Not even the initial messages in the console appeared, I am talking about the messages from the java plugin! That made it quite difficult debug, since nothing started. I managed to figure out that the boot loader that Dzzd had made, would actually bring up the mixed mode warning pop-up. I found out that I all along had copied and pasted a resource jar (menu sounds and stuff) that was signed to all my project. Removing sign got rid of mixed mode warning and the applet started, using boot loader.

Without the boot loader, the applet still didn't start. I use a script for all my builds, and in this particular instance, I used all software rendered resources, so I had one empty jar (just containing the manifest) that I didn't use, that wasn't signed, and that wasn't referenced from the applet tag, but was in the executed jar´s manifest. Not only does it not start, but the console buttons don't work, including the close and the windows [ x ] close button! Removing this empty jar made everything work just fine, but leaving it in, will completely lock everything up before the console menu even appears!!!

I do use "Class.forName(getParameter("game")).newInstance();" in my framework code to be able to separate applet, standalone specific code from my game code. Not sure if that is affecting things.

ok dont want to give to much hopes (but first try seems to work, just need to do some more tests) expecially if it finally dont solve it, but seems that I have find a really nice solution, will post some more informations tonight.

PS: the not so good thing is that it will probably be considered as a security hole and then will be patched...

seems to work pretty well... unfortunatly it for now dont solve my problem (popup & load security at runtime) but it enable something new in Applet world that give the Applet Booter all its power :

here it what it offer : delay all the jar loading (even on unsigned Applet ),applet tag do not requiere any archive tag, all jar are loaded after the applet have started this enable imediate applet start and custom loading, tested & working I ll post last details and sources code tonight.

It also enable mixing signed / unsigned without mixed warning and enable cross jar class access as long as you put the boot class in a signed jar and I suppose this one will help some of JGOs here ?

below is the HTML code, as you can see there is no archive attribute on the Applet tag all Jars loading are delayed (and it does not requiere to be signed), but I am still facing a problem :

need to put Boot.class in a signed boot.jar to enable signed/unsigned mixing Jars, because if not each Jar are considered as being unsigned, I dont like it because I would like to be able to popup the security dialog at runtime as it was running before 1.6u19 (not at startup).

how/when this dialog is poped up ? I suppose it is related to Certificat / SourceCode / ProtectionDomain or some other classe like those, but how exacly, any ideas ? for now I can load those signed Jars but the signeds one act exactly the same as unsigned : the ClassLoader load them and seems to not see / ignore (I suppose because my classloader is stamped unsigned ..) the certificat of the signed Jar/classes...

rather than doing our own plugin... we should all investigate in a trusted certificate and sign a generic Applet booter ( one like this ) and implements our own security manager ...

I know it look a bit security hole but... that what happen when security become too restrictive : people uninstall FireWall / Antivirus / Disable vista security center / click "yes" on any security dialog they are asked for / write there password on paper sheet / and so on... that's why once again I would say that Oracle have no idea of what is security or they have some commercial plan in mind

I know it look a bit security hole but... that what happen when security become too restrictive : people uninstall FireWall / Antivirus / Disable vista security center / click "yes" on any security dialog they are asked for / write there password on paper sheet / and so on...

Or they will give up and say your application/game/x "doesn't work", I don't know which option is worse

Does it though? Because when I read the actual attack / proof of concept it seemed to be that javaws was being run without validating the command line arg, which allows an attacker to pass their own -J param and path, and so boot with an additional jar.

Oracle seem to have 'fixed' the wrong thing - they're trying to load the jar file and sandbox it after the fact with classloader hackery. But it strikes me that the proper root-cause fix would be to properly sanitise the command line before passing it to javaws so that rouge jar paths can't be introduced in the first place.

That, combined with the no-beta quick roll out, has all the hallmarks of a non-technical manager throwing a hissy fit and forcing through such a colossally broken and ill-thought-out fix.

Except that u19 fixed a security issue - a gaping hole.Imo they should have done a "patch" for now and then change the stuff in java 7.

but apparently the issue was more important than screwing devs over - which I dont disagree with ...

sorry but cant understand what security hole they have fixed with the mixed-code restriction and scary popup, once you got a selfsigned library you can do whatever you want, so absolutly no need to prevent the user there will also be an unsigned code running with the selfsigned library: the selfsigned can already do what it want do to, so absolutly useless & understandable to have done such modification.

anyway they should have better validate (or at least validate...) this update before releasing, breaking existing applications is not really a way to go for web technologies.

it will give Applet all right or not depending on user response to security popup but the nice thing is that it wont show any secondary popup, it will also start imediatly and load jars asynchronously after boot applet start and then will launch the given sub-applet. if you dont requiere any special right than dont sign the booter and it will just run as fine.

java4k applet show popup, same on java.net and same on sun.com website, I just cannot find any website where there is not this popup

seems that Oracle just break in two updates all the efforts made by Sun last years to make the plugin appears more userfriendly, it is really impossible to rely on Java technologie expecially if Oracle is in the game, they always have produce poor quality tools and always focused on money

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