Program compiles fine but crashes with NoClassDefFoundError

I have written five classes, which, in a nutshell, serve the purpose of creating a GUI and recording participants for a conference. I have built panels and added them, FocusListeners, ActionListeners, ItemListeners.

From what I can gather, the message I am getting upon crash is related to my Classpath, but I don't really know how to fix it. Here is the code where the crash takes place (it is when I add the ActionListeners for the two buttons for my panel:

private void buildButtonPanel()
{
   //create the buttonpanel
   buttonPanel = new JPanel(new FlowLayout());
   //create the buttons
   calculate = new JButton("Calculate Charges");
   clear = new JButton    ("Clear");
   //add listeners to the buttons
   ConferenceHandler handler = new ConferenceHandler(this);
   calculate.addActionListener(handler);             //crash occurs on this line
   clear.addActionListener(handler);
   //create a text area
   JTextArea textArea = new JTextArea(5,30); 
   textArea.setLineWrap(true); textArea.setWrapStyleWord(true);
   //add a scrollbar to the textarea
   JScrollPane scroll = new JScrollPane (textArea);
   //add everything to the buttonpanel
   buttonPanel.add(calculate); buttonPanel.add(clear); buttonPanel.add(scroll);
}

The crash message I get:

java.lang.NoClassDefFoundError: ConferenceHandler
    at ConferenceGUI.buildButtonPanel(ConferenceGUI.java:63)
    at ConferenceGUI.<init>(ConferenceGUI.java:33)
    at IsItWorking.<init>(IsItWorking.java:16)
    at IsItWorking.main(IsItWorking.java:28)
Caused by: java.lang.ClassNotFoundException: ConferenceHandler
    at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
    at ConferenceGUI.buildButtonPanel(ConferenceGUI.java:63)
    at ConferenceGUI.<init>(ConferenceGUI.java:33)
    at IsItWorking.<init>(IsItWorking.java:16)
    at IsItWorking.main(IsItWorking.java:28)
    at __SHELL0.run(__SHELL0.java:6)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at bluej.runtime.ExecServer$3.run(ExecServer.java:774)

I know there are a lot of people here with a lot of experience, and I cannot find any help on the interwebs on this one.

Solution

As for telling java where to find ConferenceHandler (and I apologize for sounding stupid - homework questions are asked by newbs) I am using Blue Jay, and all I have to do is click on the main, and the program runs. I have no idea how to do this from command line.

The place to look is in the documentation for the java command; e.g. here. Pay particular attention to the stuff that talks about the classpath and the different ways of setting it. Also read this page.

I realized that it was a problem with classpath, and no matter what I did, I couldn't fix it. So I took all of the original classes, and pasted them all into a new folder, and it worked like a charm.

That's a Voodoo solution. You really need to understand the problem.

To that end, lets revisit some comments above:

The stacktrace indicates otherwise. They're packageless (in other words, in the default package, if BlueJ is telling that you literally somehow). – @BalusC

I wish I knew what that meant..... - @unit

What @BalusC means is that the stack trace tells you the full name of the class that it was trying to load.

    ...
    Caused by: java.lang.ClassNotFoundException: ConferenceHandler
    ...

And the full name (in this case) is ConsoleHandler ... not some.pkg.ConsoleHandler.

What is not entirely clear is why this is occurring, but I suspect that you were actually running old .class files that didn't match the source code you were looking at. And your Voodoo solution could well have "fixed" this by replacing the old .class files with new stuff. But if that's the case, you need to understand what is wrong with the way you are building / deploying. Otherwise, you'll trip over this kind of thing over and over again.