• This usually happens in unsigned Applets when you attempt to do something Applets are not allowed to do, such as read a file or talk to a server other than the one you were loaded from. You are getting slapped down by the security sandbox. However, they also occur in other contexts you would not think would be related to security, e.g. in RMI when you have a mangled serialised object, or if you try to register a duplicate RMI service name.
• Sun bug number 4809366 : The Bea JVM fails to give permission for getClassLoader even when you ask for AllPermissions.
• One common way to get in trouble is to use absolute URLs in your unsigned Applet. The Applet will then work on one website only, or locally only. Instead, use a relative URL and convert it to an absolute one like this:

  import java.net.URL;
  
  // ...
  
  URL url = new URL( absoluteOrRelativeUrlString );
  
  if ( url.getProtocol().length() == 0 )
     {
     // convert relative URL to absolute
     url = new URL ( getDocumentBase(), url.getPath() );
     }

• Watch out for this one. Sometime when you test your Applets locally they work, but when you use them on the web they fail with AccessControlException. Remember, Applets are not supposed to read files, though you can do an AppletContext. showDocument. You can however read resources in the jar file.

• You are using Internet Explorer which has a defective or missing Java.
• Missing package statement.
• These erroneous Applets will often work with the Java Plug-in, or when run locally, but will fail with native Javas when run on the web.
• There can also be problems with your jar file having too much or too little qualification of class names. Your <APPLET CODE= must have nothing but the class name, without the .class.
• Make sure the case and name exactly match the name of the *.java file, *.class file, and class name. For a class in a package this would have dots in it, e.g. com.mindprod.mypackage.Myclass, but it would not have any directory qualification.
• Your CODEBASE= parameters must have an absolute http://-style reference to the base directory where the code is stored.
• For a local hard disk, the only thing I could get to work reliably on NT with all browsers and AppletViewers is leaving the CODEBASE out entirely. You may find for your platform you have to code it something like this: ///C|//MyDir/ or C:\MyDir\.
• Your ARCHIVE= parameter must have a list of the jar files, separated by commas. If you have too little or too much qualification, or if you fail to use the file naming conventions of your server, you will be in trouble.
• 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.

// assigning ram to hold an array of ints
int[] x = new int[ 10 ];

• The first four bytes of a class file are supposed to say CAFEBABE in hex. They don’t.
• Most likely the problem is you uploaded your class file to your Web server using FTP ASCII mode instead of BINARY mode which mangled the class file.
• Sun bug number 4151665 : Sometimes when a class is not found it gets reported as corrupt instead.
• Novices get this error when they try to run a program without compiling it first e.g

  rem oops, javac.exe takes *.java
  rem java.exe takes *.class without the .class extension.
  java.exe MyClass.java

• If the class file seems ok, consider the possibility some other class file on the classpath is the one the ClassLoader is looking at.

• You have cast a Class object to a Class that is not the same class or a super class of the Class object.
• If the error message complains you have tried to cast class X to class X, it is complaining that the two different class Xes belong to different class loaders.
• If the ClassCastException occurs during a sort, chances are you forgot the implements Comparable. See the gotchas for details.
• If you write a factory method like this:

  // typical factory method, that overrides a similar method in the base class
  protected CameraButton cameraButtonFactory ( int buttonNumber )
     {
     return new LabelledCameraButton ( buttonNumber, this );
     }

  and it seems to be producing the wrong kind of objects — ones from the base class’s version of the method, check the precise spelling and signature of the method. It had better exactly match the one in the base class. If it does not exactly match, it will not override. To guard against this error Bali proposes an explicit overrides keyword.

• You mangled the class file FTP upload by doing it as ASCII instead of binary.
• Further your web server must be configured to send *.class files as binary rather than ASCII. It needs a MIME configuration entry to define *.class files. See MIME for details.
• Sometimes it is actually a CLASSPATH problem. It can’t find the class.
• ClassFormatError: class already loaded. You have a class file twice on the classpath. It has nothing to do with the DLL already being loaded. Thankfully, having a DLL still loaded from the last time you ran is not considered an error.
• ClassFormatError: bad major version. Your ancient 1.1 Java runtime does not know what to do with a program compiled under JDK 1.4..

• his occurs only at run time. Usually it means a class that was present during compilation has disappeared, or the classpath has changed so it is no longer accessible. It could also happen if you dynamically load a class and the class is not on the classpath.
• Are you spelling the fully qualified class name correctly on your Applet tag. Case matters. Double check the case of every letter.
• The class itself references another class that can’t be found. Are you using APIs from versions of Java that aren’t supported by your browser?
• Try specifying CODEBASE="." as an Applet parameter, to ensure that the browser is looking in the right place.
• Are there packages involved? If so, the Applet class needs to be in a package-appropriate subdirectory, or better still in a jar, not in the same directory as the HTML file. If not, you ought to look into putting every class in a some package before you deploy code; the default (nameless) package is intended only for test code that won’t be distributed.
• Look at your jar with winzip. Are all the classes and package names correct with the correct case? Make sure all the case information is perfect on your jar-building line.

• missing caps on new MyClass() reference.
• missing caps on MyClass() obj declaration.

• You wrote some code like this:

  // one way to trigger an ExceptionInInitializerError
  private static final int a;
  
  static {
   // someMethod throws some sort of Exception
   a = someMethod();
  }

• If the class you are loading throws an Exception during the static initialisation, it will show up as a ExceptionInInitializerError rather than the original Exception, which your code may not be prepared to handle. When your code later goes to use the class, you will get a NoClassDefFoundError.
• If you get this error when you run in Netscape, but not when debugging, check that all your class files are being included in the jar file.

• In Netscape, inner classes can’t seem to access private variables of the enclosing class. You don’t discover this until run time.
• Failing to use both the <APPLET ARCHIVE= parameter to specify a comma-delimited list of jar file names and the CODEBASE= parameter in the form of an absolute http://-style reference to where the jar file is.
• Generally problems with CLASSPATH, CODEBASE, and ARCHIVE.
• Classes in jar have the wrong amount of qualification stored with them.
• Classes in packages are not stored in the correspondingly named directories. See CLASSPATH and java.exe in the Java glossary for a fuller discussion.
• Using an old library with new code. In the old library a method might be private where in the new it might be public.

• You forgot the static on your main method.
• Any illegal use of a legal class.
• You have made a change to a class and are still referencing it from an another class by its old signatures. Try deleting all class files and recompiling everything.

• You serialised some objects, then modified the class source code a tad, say by adding another convenience constructor. Java panicked and decided the old objects were no longer compatible when you tried to read them back in. You can soothe it by manually assigning your objects class version numbers with code like this:
• It is up to you to change that number any time the class changes in a way that would affect the old object’s ability to be read back with the new class definition. Java has some flexibility for the old and new objects not to have a perfect match. serialVersionUID is a magic variable name. Spell it exactly like that. If you have used a serialVersionUID, perhaps you have actually changed the layout of the class fields without a new serialVersionUID. Finally, perhaps you failed to provide a no-arg constructor.
• You serialised some objects, then changed the format of the objects, rightly changed the serialVersionUID, then tried to read the old object back with the new class definition.

• Something went wrong with I/O, usually you got the filename wrong or presumed the wrong default directory.
• If you get it in jar.exe, your manifest is malformed.
  Main-Class: com.mindprod.canadiantax.CanadianTaxCalculator
• Note, there is no space before the colon and exactly one afterwards. There must be a line feed at the end of the line. There is no .class on the end.

Kludges around the bug include:

• Always launch Java Web Start apps inside a browser.
• Create your own desktop shortcuts with an explicit link to a local copy of the *.jnlp file and possibly C:\Program Files\java\jre1.6.0_06\bin\javaws.exe if you are unsure associations are set to use that version of javaws.exe.
• Explicitly launch the JRE javaws.exe with C:\Program Files\java\jre1.6.0_06\bin\javaws.exe -viewer and use it to launch your apps or create your shortcuts.

1. Uninstall any JREs and JDKs including the SQL database.
2. Manually strip out any remaining JRE/JDK files, including those in C:\Windows\System32, and C:\Users\user\AppData\Roaming\Sun\Java\Deployment\cache.
3. Manually delete any references to the JRE/JDK from the registry.
4. Remove any Java Web Start desktop shortcuts or menu items.
5. run a registry cleaner.
6. run NTRegOpt.
7. Reboot.
8. Reinstall the JDK with associated JRE, making sure you select a drive explicitly for each of the three pieces, the JDK, the database, and the JRE.
9. Fix up the set environment and the ext directories.

java.lang.NoClassDefFoundError: mypackage/MyClass
This one is a bitch to track down. It has so many causes. Java so picky! A misplaced comma, quote, semicolon, extraneous extension or even the wrong upper/lower case can derail the whole program. I hope some will implement the NoClassDefFound Amanuensis to make the problem easier to track down.

1. Essentially the problem is the place and name where you put the class file, free-standing on disk or inside a jar, does match the place and name it should have, based on the classpath, the package name and the class name. Everything is case sensitive, and sensitive to the tiniest typo. Unfortunately, there is currently no tool to tell you where the class should be placed (usually there are several possibilities) or where it is now.
2. You got the class name wrong on the java.exe command line. It must include the full package name and class separated by dots, without the .class e.g.
   java.exe com.mindprod.converter.Convert
   not just the class:
   java.exe Convert
   Newbies often get in trouble by adding a .java or .class suffix. In contrast, javac.exe demands the .java extension.
3. You get an error message like this: Exception in thread "main" java.lang.NoClassDefFoundError: XXX/java. When attempting to compile, you keyed java.exe XXX.java instead of javac.exe XXX.java.
4. Java can’t find the class mentioned. It is missing from the jar or classpath. Java may need it because it occurs as a class or superclass in a serialised ObjectStream or because you called a method of that class. You don’t find out about the problem at compile time or even load time. You only find out when you actually go to use that missing class. The missing class was present when the class referencing it was compiled (perhaps on somebody else’s machine) but the missing class is no longer accessible. To fix a vanilla NoClassDefFoundError, search the all the jar files on your machine for the missing class. Funduc Search and Replace will do that. If you can’t find it, scour the web for a download. When you find it, make sure its jar is on the general classpath, the project classpath, the command line classpath or in the ext directories of the various JREs you have installed. There will be at least two ext directories.
   classpath
5. Three diagnostic tools you may find helpful:
   1. To dump the classpath that you are actually using at some point in your code insert: You must first determine if the classpath is correct with:
   2. If you have a jar or more than one class, assign each class to a package! Package-less classes are for one-shot, single-class throw-away experiments only.
   3. Then when you are sure the jar or directory you want is truly on the classpath (it is not sufficient for the directory that the jar is in be on the classpath), then check the contents of the jar with jarlook to make sure your package/class is in there, spelled precisely, including case. You can download jarlook with source.
   4. download jarcheck as well. It will help you detect problems with unexpected target versions of class files in your jars.
6. Recall that reconstitution of serialized files uses Class. forName to instantiate all the classes buried in the files. Genjar or equivalent does not know to include these classes in your jar. It is up to you to include all the classes you need manually. You will keep getting the dreaded NoClassDefFoundError until you have nailed them all.
7. Look for a typo in spelling the class file name in the file or in the command line invoking its main method. Copy/paste to make sure they are absolutely identical including case.
8. Check your classpath. Make sure you used semicolons or colons as appropriate. Don’t specify null fields in your classpath, e.g. two semicolons in a row.
9. The problem is essentially either the class is not on the classpath or the classpath is wrong. You must first determine if the classpath is correct with:
10. If your program used to work and it “suddenly” stopped working, did you upgrade your JDK/JRE? If so, you likely forgot to copy over the jars to the C:\Program Files\java\jre1.6.0_06\lib\ext and C:\Program Files\java\jre1.6.0_06\jre\lib\ext directories.
11. You wrote some code like this:

    // one way to trigger an ExceptionInInitializerError
    private static final int a;
    
    static {
     // someMethod throws some sort of Exception
     a = someMethod();
    }

    If the class you are loading throws an Exception during the static initialisation, it will show up as a ExceptionInInitializerError rather than the original Exception, which your code may not be prepared to handle. When your code later goes to use the class, you will get a NoClassDefFoundException.
12. If you see the phrase “wrong name” in the error message, it means you are not consistently naming the packagename. ClassName everywhere. Perhaps you left off the packagename, or got the case wrong, or made a typo in either the package or class name.
13. If you have two packages that use classes from each other, each jar must have all the classes of the other package that it uses, or that it uses indirectly uses.
    dependencies
14. You must put the -classpath option before the class name on the java command line. To remember the order, you can think of it like this. Java.exe needs to know the classpath before it can search for the class.
15. You got package name wrong at the top of the source file, or left it out entirely. It does not match the one when you built the jar. It is case sensitive.
16. If this is an Applet, you got the <applet code="com.mindprod.mypackage.MyClass.class" wrong. Perhaps you forgot the package part of the name or you forgot the .class. The package names in the jar may not be right. The <applet archive="myjar.jar" may not match a jar file containing the needed class.
    .jar
    Applet
17. If you use java.exe -jar, it ignores your classpath environment variable and any -classpath option without comment! All your classes must be in the jar. This means for example:

    rem Vainly attempting to add an auxiliary mail.jar.
    rem It has to go in the bulk.jar manifest Class-Path entry instead.
    java.exe -cp C:\javamail-1.3.3_01\mail.jar -jar bulk.jar

    won’t be able to find any of the classes in mail.jar. You must copy mail.jar to the ext directory or mention the mail.jar in the manifest Class-Path: entry.
18. Did you remember to include . on your classpath?
19. If you got the exception trying to execute a class in a jar, check with winzip that the pathnames inside the jar on that class exactly match the package structure, including case. If you don’t know what I am talking about, see jar for details. Make sure the class you are trying to call has the expected package statement. Check the manifest to make sure the fully qualified name of the main-class is properly specified.
20. You are trying to use a program compiled under Java 1.4+ with an old Java 1.1.5 runtime, often the one in Internet Explorer. The old class library is missing many of the new methods. Any other version mismatch where you run new code on old runtimes can cause the similar problems. Check the runtime version with:

    rem getting version of java.exe
    java.exe -version

    java.lang.StringBuilder is one of the most likely candidates for a method from 1.5+ not available under earlier JVMs.
21. Have you got a simple HelloWorld working yet? If not, your problem may be in the way you installed the JDK or JRE. If you have trouble, read up on Getting Started, javac.exe, java.exe and classpath.
22. Java is case sensitive. Have you got the name of the class spelled exactly the same way everywhere it is used, including the name of the *.java file, with class names always starting with a capital letter and package names pure lower case?
23. One of your static initialisers invokes a function that uses a static field not yet initialised.
24. Did you remember to make your kickoff class, the one you mentioned in the java command line, public?
25. Does your main method have signature exactly like this?

    // what a main method declaration must precisely look like
    public static void main( String[] args )
       {
       }

26. Somehow your runtime is having trouble finding classes it could find at compile time. Check your CLASSPATH. Make sure all the classes are available.
27. Check your java.exe command line. Your current directory is crucial. You must specify fully qualified class names, without the .class extension.
28. Consider combining class files in to a single jar file. Jars cause far less trouble than individual class files, especially when you export them to a server or someone else’s machine.
29. Check that your browser supports jar files. Fortunately, all the modern ones mentioned under browsers do.
30. You can get this error if you try to run an Applet on an old browser since it will not have the needed classes.
31. Watch \ and /. In string literals \ appears as \\.
32. Make sure when developing classes for an extension i.e. class or jar files that live in the lib/ext/ folder, make sure you do not have duplicate classes. Classes from extension folders will always be loaded before any other classpath, therefore making it impossible to test other development versions not in the extensions folder. Make sure extensions *.jar’s are complete (i.e., not reliant any additional classes). Make sure the *.jar in the extensions folder is up to date. Basically only thoroughly-tested, stable code should live in the extensions folder.
33. Have you accidentally used a system package name for your own classes?
34. If every program gives NoClassDefFoundErrors, try uninstalling all Java tools and JDKs, clean out the registry, and then reinstall. Make sure you have only the latest Java on your machine.
    JDK
35. If your NoClassDefFoundError occurs only sporadically, here is a possible cause: You are running some classes in a jar file which is stored on a network mapped drive in MS Windows. Sun keeps the jar files open in order to re-load classes which haven’t been used in a while, and occasional network problems will force the jar to close. The JVM doesn’t know to re-open the jar when the network mapped drive reconnects, and simply reports that various classes (different each time) no longer exist. The solution is either make sure the network is reliable, use a network file system which doesn’t close if drives are temporarily unavailable, or locate all jar files on local drives.
36. If you change the jars used by your JSP code, make sure you manually delete the generated class files (classes in the WEB-INF tree for Caucho Resin). The womb won’t be smart enough to do that on its own and you will get all manner of NoClassDefFoundErrors.
37. If you have classes included in your project that don’t live in the same directory as the project, in Café you must also do a Project ⇒ Options ⇒ Directory ⇒ Classes to include their directories in the invisible CLASSPATH for the project. Simply including the java or class files in the project is not sufficient. Other IDEs may have similar gotchas.
38. If your code works then suddenly stops working, chances are you have uninstalled a JRE/JDK or installed a new one, and the current JDK/JRE does not have the full complement of jars in the ext directory.Sooner or later you will have to reinstall the JDK/JRE and you will lose your ext directories. You can quickly rebuild them if you maintain a bat file like this and run it after every JRE/JDK install. Adjust the file to account for where your ext dirs are and where the jars are you need.
39. Sometimes the problem is with your build. Try using ant, and a script based on one of my examples. Ant has a better chance of getting it right that some ad hoc build script.

// what a main method declaration must precisely look like
public static void main( String[] args )
   {
   }

• You are trying to boot from a non-system diskette (or disk) in Windows 95/98/ME/NT/W2K/XP/W2K3.
• The crucial loader program used in booting has been deleted from your hard disk.

• A reference variable is null, when you used it to access a field or method.
• Examine the stack trace to figure out where in the code it happening. That gives you a clue to get started. You can put some code of the form:

  // simple debugging code to check for null variables before
  // they trigger a NullPointerException
  if ( p == null ) System.out.println( "p was null" );

• to narrow it down to the precise variable giving the trouble. Then you have to sit and think about why that variable is null. The real problem could be much earlier in the code, and the problem propagated through to the point where it eventually surfaced as an exception. You must figure out where it was supposed to be set, and have a look at that code and why it is failing. Most of the time you simply forgot to initialise. The easiest way to track the causes down is using a source lever debugger such as Visual Café or JBuilder. You can trace the flow of execution, or examine the state of the universe at the time of failure. If you don’t have one, pepper your code with assertions to track down just what is null, e.g.

  // typical debugging code that prints a message if thing is null.
  ensureNotNull( thing, "thing" );
  
  // in JDK 1.4+ you can also do that with an assert.
  assert thing != null : "thing is null";

• Your ensureNotNull method might print an error message if thing is null, then throw a new NullPointerException. By making ensureNotNull final, and using an if (debug) inside ensureNotNull, the inline expansions will have no overhead in production, and you can leave the debugging assertions in place to be reactivated later if ever needed.
• Most commonly you forgot statements of the form: myArray = new int[10]; or myThing = new Thing(); See the array initialisation gotchas. These are the most common of runtime errors.
• You may not call getParameter in the Applet constructor. Move that code to init.
• Beware having two variable with the same name, one local and one instance, It is very easy to do inadvertently, and Javac will not warn you, though Jikes will e.g.

  ArrayList thelist = new ArrayList( 149 );

  instead of

  thelist = new ArrayList( 149 );

  You work with the local variable thinking you are working with the instance variable, and poof, your values are lost as soon as the local goes out of scope, leaving the instance version null. This is the way I most commonly create NullPointer exceptions for myself, when I convert a local variable to an instance one when I have to break a method up that uses the variable and forget to take out the local declaration.
• Be very careful calling any methods inside your constructors. If subclasses override them, you will be invoking the subclass’s version, which may be attempting to use fields that have not been initialised yet. You won’t get a warning message! The problem usually shows up as puzzling NullPointerExceptions. The way out is to move code out of the constructor, often to the addNotify method. However, addNotify can get in analogous problem to the constructor since it too is overridden, and it may use overridden methods.
• If the problem is in Sun’s code that you call or indirectly call, look at the place in your code where you trigger the chain of calls. Insert some debug code there to examine the parameters and the fields in any objects you pass. If you can’t track it from that, use a source code debugger like Eclipse that lets you follow program flow inside Sun’s code.
• Sometimes the problem is redeclaring a local variable with the same name as an instance variable. You might have initialised one but not the other.
• The Nice language manages to detect NullPointerExceptions at compile time instead of run time the way Java does.

• Symantec support suggests copying all the DLLs in VCP\JAVA\BIN to VCP\BIN to correct stability problems. If you do this, all debugging will cease to function. Delete any DLL in VCP\BIN that also exists is VCP\JAVA\BIN.
• Check that you fully qualified the name of your class with its package name, e.g. com.mindprod.business.TestDate in the Project section of Visual Cafe, no trailing ".class" and that the upper and lower case is precisely correct. Read the section in the glossary on CLASSPATH and under java.exe on how packages, classnames, the directory structure and the CLASSPATH all interact. If that does not solve it, I have bad news.
• Windows 95 has the most incredibly inept scheme for dealing with DLLs from different vendors that just happen to have the same 8+3 name, (even when they are stored in totally different directories). Whichever application starts first gets its DLLs installed, and every other app that comes aftward has to use them. If you start some app before VC, it may load incompatible DLLs. To avoid this, load VC first. Then the other apps may stop working. Phttt! Mr. Gates has guaranteed himself a seat in hell for this (and for the confounded registry where all configuration information for all applications is lumped in one unrestorable basket). There should be separate system DLLs and application DLLs with no possibility of DLLs provided by one vendor being foisted on some other. Try starting Visual Cafe before any other app and keep it running. It stands a better chance then of getting its own DLLs loaded.

• the receiver does not have the needed class file.
• the receiver and sender have different versions of the class file.
• your stubs are out of date.
• you screwed up something doing RMI. Try a very simple case and get that going, then gradually add complexity. When it stops working you have a much better idea where to look for the problem.

• Use Wassup to determine the java.library.path system property. It is restricted, so make sure you flip the Wassup display from safe to restricted. Your DLL must live either on that path, or in your jar without any package name. In Windows, look under System Tools ⇒ Event Viewer ⇒ Application to see the event log of DLL problems for additional clues.
• You must do a System.loadLibrary( "mylib" ) [or System. load( "C:\\libs\\mylib.dll" ) for Windows] [or System.load( "lib/mylib.so" ) for Linux] before you can use any native methods of a class.
• If you get the error after the class containing the native method is safely loaded, when you invoke a native method, make sure you generated your *.h file with the fully qualified class name:

  rem preparing .h file for native methods for class
  rem com.mindprod.mouse.Mouse
  javah.exe -jni -o mouse.h com.mindprod.mouse.Mouse

  not simply:
  javah Mouse
• If you get the error after the class containing the native method is safely loaded, when you invoke a native method, check that the *.cpp method signatures exactly match those in the *.h file. You should see method names like this: Java_com_mindprod_mouse_Mouse_GetMousePosition that start with the word Java and contain the package, class and method name all strung together. Make sure you remembered to implement all the methods.
• Put all your classes is a package. Package-less classes are just for tiny toy programs.
• If you get the error on your System.loadLibrary( mylib ) or System.load("C:\\libs\\mylib.dll") you may be missing the missing native class/dll.
• You have given your library the wrong name or specified the wrong name in the System.loadLibrary( mylib ). Details.
• If you are getting the Exception on a System.loadLibrary( mylib ) try using System.load("C:\\libs\\mylib.dll") instead of the System.loadLibrary("mylib").
• Class name not properly qualified.
• At least for debugging, move your loadLibrary call out of static init so you can catch the Exception and see the stack trace more easily and debug trace more easily.
• You need to regenerate the *.h and recompile the *.c file if you change the package name.
• In order to execute JNI methods from a Netscape Applet, the class containing the native methods must be in the client’s system class path for Netscape (F:\Program Files\Netscape\Communicator\program\java\classes). The DLL must be in the client’s DLL classpath for Netscape (F:\Program Files\Netscape\Communicator\program\java\bin). If this is not done, you will be able to load the library, but not execute methods on it. I suspect there is something broken in Netscape and System.loadLibrary. I have fooled around with it for months and still cannot get it to behave reliably. See notes under JNI and capabilities.