Applies to:
JRE version(s):
1.4.2_xx, 1.3.0_xx, 1.3.1_xx, 1.4.0_xx, 1.4.1_xx
Description:
You may encounter the following security warning when running applets on or after January 7, 2004:
Publisher authenticity verified by: “Verisign”
The security certificate was issued by a company that is trusted
The security certificate has expired or is not yet valid
or
Publisher authenticity verified by: “Verisign”
The security certificate was issued by a company that is not trusted
The security certificate has expired or is not yet valid
Cause:
Invalid JRE version
admin JAVA-JRE
Applies to:
NA
Description:
Occurs when Applet can be initiated
Cause:
* You are using Internet Explorer which has a defective or missing Java.
* Missing package statement.
* There can also be problems with your jar file having too much or too little qualification of class names. Your
* Make sure the case and name exactly match the name of the *.java file, *.class file, and class name.
* Your CODEBASE= parameters must have an absolute http://-style reference to the base directory where the code is stored.
* Your ARCHIVE= parameter must have a list of the jar files, separated by commas.
* You tried to do something in an unsigned Applet only signed Applets are allowed to do such as reading restricted system properties, perhaps indirectly via Color. getColor.
admin JAVA-JRE
Applies to:
NA
Description:
Each class file starts with special 4 bytes equal to the hexadecimal value of 0xCAFEBABE – this number identifies the class file format and is humorously named “Magic Number”. When you get an error from the JVM saying “Bad Magic Number”, it simply means the class file it is trying to load is corrupt (or perhaps the JVM is corrupt).
Cause:
Class file or JVM is corrupt
admin JAVA-JRE
Applies to:
NA
Description:
This is a common mistake that occurs when you have ftp’ed (uploaded) your .class files under the ascii format
Cause:
You have (uploaded) your .class files under the ascii format
admin JAVA-JRE
Applies to:
NA
Description:
Occurs when Your class files use newer JRE.
Cause:
Most likely your class files use a more recent version of Java than the Java runtime you are using. This most commonly happens with Applets in Internet Explorer which supports only an ancient version of Java.
admin JAVA-JRE
Applies to:
NA
Description:
Occurs while reading zip file.
Cause:
You have used ZipInputStream to read a zip created by ZipOutputStream
admin JAVA-JRE
Applies to:
NA
Description:
When attempting to run an applet within Microsoft Internet Explorer the applet appears as a grey rectangle, with no activity and the applet is most definitely not running.
Moving the cursor over the grey applet area may reveal the message:
load: class xxx not found
where ‘xxx’ is the name of the applet.
Cause:
a. The most likely cause is that the class name is misspelt. This is unlikely to be the problem for pages viewed over the web, where it can normally be assumed that the webmaster would have resolved such issues. If the name is misspelt (or the class is genuinely not available) then only the developer can resolve this.
b. There may be a mismatch between the version of the Java SDK that the applet was created with and the version of the Java RE (run-time environment) locally environment installed. This is only an issue if the applet was created with a later version of the Java SDK than the local Java RE. Note: This only seems to be a problem with Internet Explorer.
admin JAVA-JRE
Applies to:
NA
Description:
Occurs while parsing of invalid XML file.
Cause:
You have passed to the parser invalid or corrupted XML file.
admin JAVA-JRE
Applies to:
NA
Description:
Occurs when You have tried to open a large number of files and exceeded a limited system resource.
Cause:
You have tried to open a large number of files.
admin JAVA-JRE
Applies to:
NA
Description:
Occurs while file uploading to the server.
Cause:
The main reason is that the underlying socket was closed or reset. The most common reason is that the user closed the browser before the file was fully uploaded. Or the Internet was interrupted during the upload. In any case, the server side code should be able to handle this exception gracefully. Also some clients do not send multipart properly.
admin JAVA-JRE