Classes not found for jars listed in manifest

Question

I have an applet whose main jar has a number of dependent jars listed in the manifest. All the jars are signed.
The applet works fine when downloaded from an HTTP server.
Previous to 1.6.14 it would also run from a local directory.
As of Java 1.6.15 and 1.6.16, the classes in the dependent jars are no longer loadable from the local directory. ClassDefNotFound is the reported on the java console. Obviously the class is present, as the application is running fine in JVMs 1.6.14 and previous.
I see that 1.6.16 includes changes for the security baseline, but I cannot find anything that suggests changes are needed to support dependent jars. None of the dependent jars request a specific version of JRE.
Anybody know what is going on?

Answer 1

Is this the error? ...Yes, sorry, the exception is NoClassDefFoundError
If you provide a Short, Self Contained, Correct Example someone may be able to diagnosis the problem, as opposeed to guessing. A link to the real live application can be found at: http://download.equitrac.com/38834/InstallGUI.html. (This original application does not meet the definition of short ... but demonstrates the problem well.)
When run as an applet off this site, it works fine.
If you click on the download button, it will place a copy on your local harddrive. To execute it locally double click on your local copy of InstallGUI.html.
When running it locally with Java 1.6.15 and 1.6.16 it will give you a class def not found exception without doing any thing.
When running locally with Java 1.6.14, it will not experience any trouble.
This applet needs permissions to open sockets and store data on the harddrive.
Probably due to the presence of class files that once existed outside of the jars, but are now not thereClose ... the application is made up of a main jar (our product) and a number of third party jars. The manifest for the main jar properly references the other jars, and works in all JVMs before 1.6.15. As of 1.6.15, none of the classes from the referenced jars can be opened.
I found that I can work around the problem by placing all classes into a single jar ... which may infringe on licensing requirements for some of the third party jars we use.
Dave