Yet another NoClassDefError Problem
Okay, here's the deal. I recently got a new computer. I installed the JDK 1.5.0, and then transfered my source code and class files onto the new computer. My old computer has Windows 98 SE, and my new computer (a Toshiba Satellite) has Windows XP Home, Service Pack 2. javac works fine, but for some odd, unknown reason java.exe continually states that it cannot locate the class files. Those class files worked perfectly on my old computer.They compile without error using javac.exe. I had no problems with the installations and have tried reinstalling the JDKs and JREs several times now. There was no change. The class files were origionally compiled with the JDK 1.4.2 on my old computer, but I have recompiled several of them with the JDK 1.5 compiler resulting in no change.
I decided to install JDK 1.4.2 to see if it would work. It doesn't either. No matter which version of java.exe I try to use, it throws a NoClassDefFound error when I'm using the command line. It didn't work through NetBeans, either. jEdit gives me an IllegalArgumentException.
This is not a classpath problem. I am trying to run java.exe in the directory where the class is located using java.exe's full path (C:\Program Files\...\bin\java). I am absolutely certain I have the right location for the class files. The dir command lists it! Some of the class files I tried aren't packaged, so there's no issue with that.
There is a functioning main method.
This is not a problem with a single class. This is something system-wide.
I honestly can't say if it's Windows or if it's Java. I've tried everything I can think of. Any suggestions? And do you think I should post a new bug about this?
> I've tried everything I can think of. Any suggestions?
No class definitions are always, by definition, a class path error.
There are any number of reasons that might occur.
1. It isn't in the class path.
2. There is an error in the class path (the VM will stop reading if it encounters an error.)
3. The included items do not actually have the required items
4. Something is corrupted.
> And do you think I should post a new bug about this?
It isn't a bug in java.
You first start by running the following command in a console window.
java -version
Then you create a new directory, a new helloworld class file and then run that from a console window explicitly setting the classpath on the command line.
>1. It isn't in the class path.
I'm using DOS. The dir command lists the class. java.exe uses the current directory if no classpath is specified by -classpath.
>2. There is an error in the class path (the VM will stop reading if it encounters an error.)
Which class path? The one I'm setting with -classpath? I'm not using that option. I'm running from in the directory. I'm also using the full path of java.exe, rather than the autoexec.bat's classpath.
Hmmm..... If I am accessing java.exe using the full path (C:\Program Files\...\bin\java), might it try to run it in java.exe's directory rather than the current directory?
>3. The included items do not actually have the required items
I've tried this on a class that literally has nothing but a main method and the only other class it requires is System. java.exe isn't finding the class containing the main method.
>4. Something is corrupted.
In Windows, perhaps I suppose, but I've tried reinstalling both JDKs. I don't think that any of the Java elements are corrupted. What could possibly be corrupted in Windows that would cause this problem but not totally screw up my computer?
*curses lack of an edit function*
> You first start by running the following command in a
> console window.
>
> java -version
>
> Then you create a new directory, a new helloworld
> class file and then run that from a console window
> explicitly setting the classpath on the command line.
I assume you mean a console window such as DOS. By the way, I'm definitely beyond a HelloWorld program. I'm making a board game and teaching myself Swing and learning a little bit about streams to do it. =)
> I assume you mean a console window such as DOS.
Yes.
> By the
> way, I'm definitely beyond a HelloWorld program. I'm
> making a board game and teaching myself Swing and
> learning a little bit about streams to do it. =)
That might be, but given that you are claiming nothing is working then you need a minimal and guaranteed non-corrupt version to test with.
Well, how can I guarentee that it isn't corrupt?And please look up at my first post and answer my question about where it's running java.exe if you can.I don't suppose you'd know how to append the Windows XP classpath so I wouldn't have to use the full path, would you?
*curses lack of edit button again* first response to your post, not my first post.
As much as I hate to triple post, I'm at my computer instead of at school right now and realized I could post the actual error.
C:\DOCUME~1\BLADEO~1\JAVAWO~1\JAVAPR~1>"C:\Program Files\Java\jdk1.5.0\bin\java" ViewUnicode
Exception in thread "main" java.lang.NoClassDefFoundError: ViewUnicode
ViewUnicode just starts a char at 1 or 0 (I forget which, but that's not important) and increments it by 1 and prints it with System.out beside the char casted as an int. All of that is inside it's main method, it's only method.
There is a PATH environment variable that is associated with Windows, not Java. It provides a list that Windows searches for commands that it can't find in the current directory. When you type "java" this is what allows Windows to find the command. See the Installation Instructions for the Java package you downloaded, #5, for instructions to set this.
The CLASSPATH is another environment variable that is used by Java to find classes and .java files. This can be set permanently in the same manner as PATH.
DO NOT DO THIS until you read and understand the 2 documents on this page that discuss CLASSPATH and How Java finds Classes:
http://java.sun.com/j2se/1.5.0/docs/tooldocs/index.html#general
> java.exe uses the current directory if no classpath is specified by -classpath.
Your above statement isn't correct. Setting either the CLASSPATH variable or using the -classpath command-line option overrides that default. To include the current directory you must include "." in the classpath setting.
Do this:
First, make sure that the file <yourClassName>.class exists with the .class extension and you know where it is.
Change to the directory that <yourClassName>.class is in, and issue the following command. Make sure that it includes the spaces and dot (period) as shown:
<pathToJava.exe>java -classpath . <yourClassName>
If this works, then the problem is definitely a classpath problem.
> There is a PATH environment variable that is
> associated with Windows, not Java. It provides a list
> that Windows searches for commands that it can't find
> in the current directory. When you type "java" this is
> what allows Windows to find the command.
Believe it or not, I learned that when my teacher last year had us set it in autoexec.bat when we installed the JDK. ;) Unfortunately I don't know how to do this in XP...
>See the Installation Instructions for the Java package you
> downloaded, #5, for instructions to set this.
... which is why I thank you for that recommendation. =) Although I wish you wouldn't assume I have no clue what I'm doing. It's rather... degrading. I do have some idea what I'm doing. Unfortunately, I never took the time to read that.
> The CLASSPATH is another environment variable that is
> used by Java to find classes and .java files. This can
> be set permanently in the same manner as PATH.
> DO NOT DO THIS until you read and understand the 2
> documents on this page that discuss CLASSPATH and How
> Java finds Classes:
> http://java.sun.com/j2se/1.5.0/docs/tooldocs/index.html
> general
I'll have to read that. *looks at the URL* Tooldocs? Interesting....
> > java.exe uses the current directory if no classpath
> is specified by -classpath.
>
> Your above statement isn't correct. Setting either the
> CLASSPATH variable or using the -classpath
> command-line option overrides that default. To include
> the current directory you must include "." in the
> classpath setting.
Okay, you're saying that it defaults to what? It defaults to the current directory as its classpath if and only if you don't create a CLASSPATH enviroment variable? I was slightly thrown by your saying that using -classpath overrides the default of using the current directory. I wouldn't call overriding it with an Envrioment Variable and overriding at runtime the same thing. An Eviroment Variable is a perament change, while specifying at runtime changes it that time only.
> Do this:
>
> First, make sure that the file <yourClassName>.class
> exists with the .class extension and you know where it
> is.
*sighs* Isn't this the third or forth time I've said I did that? Maybe even the fifth?
> Change to the directory that <yourClassName>.class is
> in, and issue the following command. Make sure that it
> includes the spaces and dot (period) as shown:
> <pathToJava.exe>java -classpath .
> <yourClassName>
>
> If this works, then the problem is definitely a
> classpath problem.
I appended the PATH variable. It's finding java without me having to include the full path anymore, but I also I just found a CLASSPATH Enviroment variable I didn't create.
This is what it contains: "C:\Program Files\Java\j2re1.4.2_03\lib\ext\QTJava.zip"
QTJava.zip seems to have something to do with QuickTime considering it contains files named quicktime. Do I need this for anything? There's another one in Windows\system32. Will it mess up something (specifically, QuickTime, of course) if I change or delete this variable?
I should have admitted it's a classpath problem long ago. I suppose it was pride that kept me from actually saying it in response to jschell. Sorry about that, jschell.
I'll still check out that document about how Java finds classes, but I don't want to permanently set that path. I have several directories that my programs are mixed throughout and it wouldn't be useful to have it permanently set.
Gah... *realizes that makes it look like he's inept at BBCode, wishes there were an edit function*
> Well, how can I guarentee that it isn't corrupt?
>
> And please look up at my first post and answer my
> question about where it's running java.exe if you can.
>
> I don't suppose you'd know how to append the Windows
> XP classpath so I wouldn't have to use the full path,
> would you?
Repeating what I said before with more detail.
1. Open a console window.
2. Type the following command (exactly as it is)
java -version
Analysis:
1. This should print something like the following....
java version "1.4.2_04"...
2. If it prints nothing then your path (not your class path) is wrong. You correct your path on XP by using
start->settings->control panel->system->advanced->environment variables
Most likely all your need to do is find where your java dir is in the current PATH and move it to the beginning. There will be two of them, move them both.
Once you do this you MUST close existing console windows. Then reopen and try the test again.
> > Well, how can I guarentee that it isn't corrupt?
> >
> > And please look up at my first post and answer my
> > question about where it's running java.exe if you
> can.
> >
> > I don't suppose you'd know how to append the Windows
> > XP classpath so I wouldn't have to use the full
> path,
> > would you?
>
> Repeating what I said before with more detail.
>
> 1. Open a console window.
> 2. Type the following command (exactly as it is)
>
> java -version
>
> Analysis:
> 1. This should print something like the following....
>
> java version "1.4.2_04"...
>
> 2. If it prints nothing then your path (not your class
> path) is wrong. You correct your path on XP by using
>
> start->settings->control
> panel->system->advanced->environment variables
>
> Most likely all your need to do is find where your
> java dir is in the current PATH and move it to the
> beginning. There will be two of them, move them both.
>
> Once you do this you MUST close existing console
> windows. Then reopen and try the test again.
o_O Doesn't anyone 'round here read stuff that wasn't specifically directed to them?
I didn't even have anything in the Path Enviroment variable to make it search for java that way. However, it does seem there is a java.exe in C:\Windows\system32, which there is a reference to in Path. Regardless, I was using the full path (C:\Program Files\...\bin\java) to run it anyway. If you'd read through what's between your last post yesterday and this one, you'd see that it was because something set a CLASSPATH enviroment variable that I was experiencing problems.
And if ChuckBing had also read what had been written, he would have known I'd already eliminated standard problems like having the wrong directory.
I've got working now. I deleted that CLASSPATH enviroment variable, which was a reference to some QuickTime zip file located inside the JDK's directory. o_O I hope QuickTime continues to work properly.
Does anyone want to hazard a guess as to where that CLASSPATH enviroment variable came from? You would think QuickTime, but it's in the JDK's directory, which I installed long after QuickTime. Might the JDK have done it at installation?
> And if ChuckBing had also read what had been written
I read what you wrote, but what you wrote showed me that your knowledge of how to configure a Java installation was limited, so I wrote a full set of instructions at the basic level.
You really should lose the attitude that you're displaying. And don't worry, I'll not bother to reply to your future posts, as you obviously don't appreciate the assistance.
>
> And if ChuckBing had also read what had been written,
> he would have known I'd already eliminated standard
> problems like having the wrong directory.
My impression was that you were bouncing all over the place trying things randomly and reporting on every single one of them in a haphazard manner.
And I don't have time to try to figure out the specifics of what you had and hadn't done.
As far as I saw you only suggested explicit pathing once. And I just figured it was one more seemingly random jump.
Not to mention that you continued to assert that you did know what you were doing and yet keep referring to things that obviously indicated that you had no idea what you were doing (like not knowing how to set env vars and referring to autoexec.bat.)
But unlike ChuckBing I might still help you in the future, but only in so much as that your posts actually make sense.
*sighs* You know something, you're right about my attitude. Here I am asking not to be patronized while I'm trying to patronize the two of you. I'm very sorry.
Ermm, okay, this might be a bit late to help you, but I decided to post it in case anyone else stumbles onto this problem and this thread...
Your problem lies here:
"I appended the PATH variable. It's finding java without me having to include the full path anymore, but I also I just found a CLASSPATH Enviroment variable I didn't create.
This is what it contains: "C:\Program Files\Java\j2re1.4.2_03\lib\ext\QTJava.zip"
QTJava.zip seems to have something to do with QuickTime considering it contains files named quicktime. Do I need this for anything? There's another one in Windows\system32. Will it mess up something (specifically, QuickTime, of course) if I change or delete this variable?"
On my machine QuickTime 7 totally meshed with Java 1.5's classpath causing the NoClassDefError problem. To fix this edit your environment variables as so:
- Remove the CLASSPATH pointing to QTJava.zip
- Remove the other variable pointing QTJava.zip (can't remember the key)
- Remove the QuickTime path from PATH
Now Java should be working again (if your path is set up correctly).
QuickTime still works after these changes.
It just goes to show ... NEVER trust Apple!
