JDK-6320113 : ClassFormatError instead of ClassNotFoundException
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-09-06
  • Updated: 2014-02-27
  • Resolved: 2006-08-22
Description
FULL PRODUCT VERSION :
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
Instantiation of a non existing class throws a java.lang.ClassFormatError instead of a java.lang.ClassNotFoundException when the application resides in a jar file which has "." in the class-path entry in the manifest file.
Only occurs when using http protocol, not file://.....
Tested on Internet Explorer 6.0 and Mozilla Firefox 1.0.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. create a test class: see code below

2. create a manifest file:
MANIFEST.MF:
********************************
Class-Path: .

********************************

3. create a jar file:
jar cfm test.jar MANIFEST.MF Test.class

4. create an html file:
test.html:
********************************
<html>
<head>
</head>

<body>
<object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93">
	<param name="code" value="Test">
	<param name="archive" value="test.jar">
	<comment>
		<embed type="application/x-java-applet;version=1.5" code="Test"	archive="test.jar">
		</embed>
	</comment>
</object>
</body>
</html>
********************************

5. put the files on a webserver
the bug only occurs when used through http.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
java.lang.ClassNotFoundException
ACTUAL -
java.lang.ClassFormatError: Truncated class file

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.ClassFormatError: Truncated class file
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(Unknown Source)
	at java.security.SecureClassLoader.defineClass(Unknown Source)
	at java.net.URLClassLoader.defineClass(Unknown Source)
	at java.net.URLClassLoader.access$100(Unknown Source)
	at java.net.URLClassLoader$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(Unknown Source)
	at sun.applet.AppletClassLoader.findClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at sun.applet.AppletClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClassInternal(Unknown Source)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Unknown Source)
	at Test.init(Test.java:7)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Exception in thread "thread applet-Test" java.lang.NullPointerException
	at sun.plugin.util.GrayBoxPainter.showLoadingError(Unknown Source)
	at sun.plugin.AppletViewer.showAppletException(Unknown Source)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.*;

public class Test extends JApplet {

    public void init() {
        try {
            Class.forName("non.existing.Class");
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
I can leave the current dir out of the class-path entry.

Comments
EVALUATION the problem is in the PluginCacheHandler.get implementation in 5.0; in 5.0 we do both cache up and resource download in the get method (put is not implemented), so when we failed to download (in this case trying to download a non-existent url), we will still try to return a response with a empty input stream in it, which triggers the classLoader to read from the empty input stream and throw the classFormatError. The problem does not exists in mustang, because we properly implement the get and put method of the cache handler; if get failed, we simply return null instead. (no longer return a response with empty inputstream in it.
22-09-2005

EVALUATION this is not reproducible with 6.0 with 5.0 the bug can be reproduced if plugin caching is enabled; if caching is disabled, bug does not occur.
22-09-2005