P4
J2SE Version (please include all output from java -version flag):
Java 7 Update 25, 40 (build 40), and 45 (build 10)
Does this problem occur on J2SE 6ux or 7ux? Yes / No (pick one)
Not before 7u25 new security enhancement
Operating System Configuration Information (be specific):
Windows 7 (but likely not OS dependent)
Hardware Configuration Information (be specific):
Dell Precision M4400 (but likely not hardware dependent)
Bug Description:
Oracle has recently changed the Java Plug-In security model that if one cannot reliably guarantee that all resources used by the applet but
loaded via the applet classloader are in jar files, then their applets will exhibit unacceptable behavior. If the resource in question is a Java class, then their applet will fail with a NoClassDefFoundError stating that the class is not signed. If the resource in question is not a Java class then a warning dialog about mixed code will be presented to the user, encouraging them to block the user. In both cases the behavior is intolerable and leaves applet authors that cannot guarantee jar completeness (and those that intentionally leave some frequently modified properties files outside all jars, for instance) with no means to reliably deploy their applets.
At a minimum, a means for a signed jar to express and extend trust in the server codebase is required.
Steps to Reproduce (be specific):
1) Sign all your applet jars but leave some of classes and other files (e.g.
properties files) which are loaded via the applet classloader absent from
the jar files but present in the server codebase directory.
2) Use the applet functionalities that require the classes and files which are
present only in the server codebase.
Java 7 Update 25, 40 (build 40), and 45 (build 10)
Does this problem occur on J2SE 6ux or 7ux? Yes / No (pick one)
Not before 7u25 new security enhancement
Operating System Configuration Information (be specific):
Windows 7 (but likely not OS dependent)
Hardware Configuration Information (be specific):
Dell Precision M4400 (but likely not hardware dependent)
Bug Description:
Oracle has recently changed the Java Plug-In security model that if one cannot reliably guarantee that all resources used by the applet but
loaded via the applet classloader are in jar files, then their applets will exhibit unacceptable behavior. If the resource in question is a Java class, then their applet will fail with a NoClassDefFoundError stating that the class is not signed. If the resource in question is not a Java class then a warning dialog about mixed code will be presented to the user, encouraging them to block the user. In both cases the behavior is intolerable and leaves applet authors that cannot guarantee jar completeness (and those that intentionally leave some frequently modified properties files outside all jars, for instance) with no means to reliably deploy their applets.
At a minimum, a means for a signed jar to express and extend trust in the server codebase is required.
Steps to Reproduce (be specific):
1) Sign all your applet jars but leave some of classes and other files (e.g.
properties files) which are loaded via the applet classloader absent from
the jar files but present in the server codebase directory.
2) Use the applet functionalities that require the classes and files which are
present only in the server codebase.