I've been trying to get a mixed code applet to load until 7u10, without much luck. The frustration is stemming from the fact that I've found lots of reports of people asking the same questions as me, but with no examples of working setups, and no straightforward answers.
We've got an applet that makes use of some third-party JARs. Our previous developer had been unpacking the other JARs, and then re-jar'ing (is that a word?) all of them along with our own .class files, into one huge JAR. That file then got self-signed. The applet itself is loaded from a simple HTML page, all loaded from disk. No webserver, no JNLP, nothing like that.
This mostly worked but the re-jar'ing is a pain to maintain now that the previous developer has left. What I want to do instead is leave the third-party unsigned JARs alone and intact. So I compile our own applet code, jar it up along with a manifest containing Trusted-Library: true, and sign that JAR instead. Then we list all the JARs in the applet's HTML file. In theory, according to the link above, our signed applet should be able to use the unsigned code.
Instead, it throws a NoClassDefFoundError as soon as anything tries to instantiate one of the unsigned classes. The link above talks about properties and resource bundles, but we're not making use of any of those things (it's a really simple applet). It's the exact same complaint as found in this forum's threads here and here, but the only answer given in those involved Class.forName and reflection... which made no sense in the context there, at least not to me.
This doesn't seem to be an unreasonable thing to want to do, but I can't find anybody talking about achieving it successfully.
edit: forum composer claims link insertion works, but it lies...
 Trusted-Library: true not working
 Re: How to avoid SecurityException with JRE 1.6.0_19 update
Edited by: 977377 on Dec 17, 2012 4:39 PM
I'm sorry, I don't have anything for you regarding that particular feature. And after reading that Oracle document with all of its caveats I would quite likely shy away from using it myself.
However, have you considered the middle way of signing all of the jars with your certificate? You would only have to sign the third-party JARs once, and then make sure that the applet's archive refers to the signed versions. I thought I had done this myself at some point, and I'm pretty sure I did, but I can't track down any concrete evidence of my activities. Not very professional, I know...
I haven't tried it before, but only because I'm assuming that signing third-party JARs would be a legal no-no. Or at the very least could open the door to some really, truly, pants-on-head retarded, asinine accusations from end users ("That file over there had a bug, and even tho it wasn't your file nor your bug, you signed the file therefore you were certifying that it was okay therefore it's your fault, give me money"). That's how tech lawsuits in the country where I live tend to run, anyhow...
It's definitely worth trying locally, even if just to get more data points.
Well, yeah, when I signed the Apache jars it was for an applet which is only used inside the company. I did read the licences and decided that signing the jars wouldn't violate them, but you raise a different point. Obviously IANAL so I'm not going to try to talk you out of that point, and it might just be that Oracle invented the feature you're asking about just because of that. They do have lawyers and know how to use them, after all.
Well, I think signing all the JARs would have worked if somebody other than me were responsible for figuring out how to load them. Simply listing them in the applet loading page like
archive="ourcode-signed.jar, 3rd-party-signed-1.jar, ..., 3rd-party-signed-N.jar">
causes a NoClassDefFoundError as soon as anything from any third-party jar is mentioned. The JRE trace file shows the proper .jar filenames being loaded ("Plugin2ClassLoaded.addURL parent called for full_path_to_correct_file"). Looking at the signed files with "jar tvf" shows that the classes are all there, proper pathnames and whatnot, they're just magically no longer usable.
The original developer had been unpacking all of the third-party JARs, and then when it came time for us to make ours, all the .class files from everywhere were being bundled back up into a single massive file. Which causes a ton of warnings and complaints because of "duplicate" META-INF/* entries, one from each original JAR. My hope was that in splitting the unchanging JARs out into their own files, this would all become a lot more manageable, but that's apparently not doable.
Oh well. Back to one huge file I guess. :-( I appreciate your time and suggestions nevertheless!