Sudden CLASSPATH errors have halted my progress

I have a Netbeans project with a CLASSPATH problem that came out of nowhere and I cannot solve. What's especially maddening is that everything compiled and ran fine until Sunday. On Sunday I changed the parental order of components in the design view and now nothing works.

Aside from core Java code like Swing, this is a project where all of the code is based within the project itself. Everything is grouped into 5 different packages, but they are all within the project.


After changing that parental order I would get either one or the other error: NoClassDefFoundError and ClassNotFoundException (I'm going on memory on those names) that would happen inconsistently.

I decided to delete my app's main Frame class and recreate it. Now when I drag my custom components to the Frame to rebuild some classes give me:

Quote:

---

"Cannot load component [package].[file] from project:
[full path to my project]
The class must be compiled and must be on the classpath of the project to which this form belongs"

---

If I forcibly add the source's path to: Project Properties ==> Libraries ==> Compile
I get this error when attempting to add my component to my default Frame class in design view:

Quote:

---

"The component cannot be instantiated. Please make sure it is a JavaBeans component."

---

I've done all of the basics to fix the problem:

• I've restarted Netbeans.
• I've rebooted.
• I've cleans and rebuilt numerous times.
• I have closed an of the windows within Netbeans to ensure I'm not accidently pulling similar files from other projects

NOTHING HELPS!

Then I tried more advanced stuff. I created a flat version of my project so that everything is in the same package. "How could CLASSPATH errors occur now?" I thought, but I still got errors! I even moved everything into the default package and continued to get that "The component cannot be instantiated..." error!



I avoided modifying the CLASSPATH until today. From what I've read, CLASSPATH is a lot like the PATH environment windows uses to search for DLLs: CLASSPATH is used system-wide so any Java tool like "java" or "javac" will use the paths. Obviously the system-wide CLASSPATH should not be modified, but I thought that even the project-level CLASSPATH shouldn't be modified either. Shouldn't Netbeans be smart enough to figure out the appropriate CLASSPATH for files LOCAL to the project?

I changed it anyway and still get errors.


A CLASSPATH error doesn't even make sense in this situation.

1. 1) All of the classes used in my project are either default-Java classes (Swing etc) or classes defined within the project itself. I have no need to search elsewhere, so why would a project designed like that ever need to override the CLASSPATH setting?
   
   
2. 2) According to the docs, the default CLASSPATH is the current directory. So why do I continue to get errors after pulling all of the classes out of their packages and move them into the same package? Even when I move them to the default package the errors remain!
   
   
3. 3) Considering these exact same classes built and ran fine once, why would moving their position (and parental hierarchy) on the GUI builder affect java & javac's ability to find these classes?

If my CLASSPATH error is a legitimate CLASSPATH error then certainly moving all of my classes into the same place would solve this. Since it doesn't I'm forced to conclude this is somehow a problem with my code that's not caught by the compiler or a bug in Netbeans.


Here's the main document I used for this research:
http://docs.oracle.com/javase/1.3/do...classpath.html

BTW: If I manually attempt to add one of these controls to my JFrame-derived class using the source editor instead of the design editor, I get some weird behavior.

In the constructor of the frame class, if I attempt to create a variable of the problematic panel I get the distinctive red squiggle under the name of that class. It's understandable since I haven't added the import statement to that class. If I select "Fix Imports" from the right click menu it plays the *ding* noise and nothing more. If I manually import the class file, then it's happy.

If I do nothing more with this problematic panel than instantiate an instance of it, clear the IDE log, and run I literally get a bucket load of errors: with many having to do with CLASSPATH.

Have you tried changing the order back to how it was to see if the change of order really is the problem or if it is just a coincidence that your compile time problems started at the same time.

I haven't used NetBeans for some time but I doubt the CLASSPATH veriable would have any effect. This variable is only used by java and javac if no classpath parameter is supplied when they are invoked, NetBeans will almost certainly be providing a classpath parameter.

You could always try compiling from the command line to see if it's a NetBeans project setup problem.

So now I have removed an unnecessary inner class, and references to it, and things started working again. I restored the code I deleted and ran the updated code. It CONTINUED to build just fine.

I decided to clean and rebuild and I'm getting an error: " Directory C:\[My Path]\build creation was not successful for an unknown reason"

None of this makes any sense.

Quote:

---

Originally Posted by keang

Have you tried changing the order back to how it was to see if the change of order really is the problem or if it is just a coincidence that your compile time problems started at the same time.

---

I have very few backups of complete sets of the files. I do have backups in my Carbonite archive but they wouldn't represent complete sets. The strange thing is my most recent backup is giving me grief too and I *think* (but not certain) that this was made before the issues popped up.

Quote:

---

I haven't used NetBeans for some time but I doubt the CLASSPATH veriable would have any effect. This variable is only used by java and javac if no classpath parameter is supplied when they are invoked, NetBeans will almost certainly be providing a classpath parameter.

---

That's what I thought. I mean, if I was grabbing distant foreign jars or 3rd party class files at compile time or runtime then I can see the CLASSPATH being an issue, but this? It makes no sense whatsoever.

Quote:

---

You could always try compiling from the command line to see if it's a NetBeans project setup problem.

---

I might have to do that. I've been checking my IDE log and I'm seeing other bizarre things like an error saying that the start of one of my functions is incorrect. It's perfectly fine and has been working fine for weeks.

I'm unfamiliar with using the javac command line compiling tool, but I did figure it out well enough to successfully compile all of the packages (and therefore all of the files) into .class files without any trouble. At this point I believe there has to be a Netbeans glitch going on or maybe I somehow screwed up some sort of java compiler's command line argument.

I'm glad I read that other thread on this forum because I completely forgot that I had Eclipse installed on here too. I'm going to give that Java tool a try.

It's unlikely to be a bug in Netbeans - compilation would be rigorously tested and as you have said it was working. It's more likely that either you have inadvertently changed a setting in the project or maybe part of NetBeans has become corrupted.

Quote:

---

Originally Posted by keang

It's unlikely to be a bug in Netbeans - compilation would be rigorously tested and as you have said it was working. It's more likely that either you have inadvertently changed a setting in the project or maybe part of NetBeans has become corrupted.

---

I don't know why the Help==> Check for Updates command in Netbeans failed to detect this, but there actually was an update and a pretty big update at that. I had 7.0.1 and the new version is 7.1.1. I upgraded to that version and so far *knock on wood* the problem has vanished.