I’m trying to teach myself how to design websites using servlets & JSP, so I bought a book on the subject and have started going through the exercises. One of the first programs starts off with these statements:
It doesn’t seem to complain about java.io, but it says that javax.servlet and javax.servlet.http do not exist.
I’m using J2SE SDK 1.5.0_04 and I have added to the end of my PATH variable “C:\Progam Files\java\jdk1.5.0_04\bin” (Windows XP, BTW)
My BIL suggested that I needed to get J2EE, so I downloaded J2EE SDK 1.4.0_03 and installed that, and changed my path to the new location (“C:\Sun\AppServer\jdk\bin”), but the program still won’t compile.
Actually at this point I’m using jEdit, which is just a step above Notepad. The book suggested using a simple editor for the first part, and then going to an IDE later, after the concepts were learned.
It looks like my system doesn’t currently have a CLASSPATH variable set up. What should I set it to?
You need to find the j2ee.jar file. It might be under the jdk directory(JDK stands for Java Development Kit). Once you’ve found it, make sure that the CLASSPATH environment variable contains the full path to the j2ee.jar file.
This is the kind of tedious detail that an IDE will take care of for you.
Edit: If the CLASSPATH needs to contain multiple entries, you must separate them with semicolons(under Windows, anyway).
You need to find servlet.jar, or maybe servlet-api.jar, or possibly javax.servlet.jar (I would have guessed it would be in your J2EE lib folder), and add that to your classpath.
I’m not sure why your book would have discouraged you from using an IDE (Eclipse!). I think it generally makes things easier. Code completion, source and output organization, build path configuration (which is what you’re trying to do here). Why would you want to be without these things. Maybe it’s a “do it the hard way first, so you’ll understand more about how things work behind the scenes later” approach, which I guess I can’t argue with.
Edit: Pretty much what Rysto said, except I guess j2ee.jar is another possibility.
j2ee.jar is in the C:\Sun\AppServer\lib folder, which I set the CLASSPATH to (both with and without a trailing backslash) and it still doesn’t compile. Yes, I am opening a new cmd window after each change.
I think I’m going to get Eclipse and try that out.
Thanks, everyone for your advice.
ETA: I couldn’t find the jar files that MrSquishy mentioned.
set CLASSPATH=.;C:\Sun\AppServer\lib\j2ee.jar;<other jars…>
If you are looking for a particular class file, you can use Windows Find to locate an appropriate jar file.
Just point Find to an appropriate search location fill in the “Search for files or folders named:” field with “*.jar” and the “Containing text:” field with the offending class name.
For example, I put in HttpServlet and it found the jar.
Even though a Jar is a zipped file, it seems that there is some index information uncompressed that is found by Windows find, so this is a convenient means of finding the jars.
In case you are doing what it sounds like you are doing - a folder in the classpath setting indicates that it is supposed to look for .class files and resources underneath that directory. As indicated by other posters, you want to specify the actual full path to the j2ee.jar file in the classpath, NOT the folder containing the jar file.
A jar file is just a zip archive with some metainformation. You can open it with a zip utility, and see that it contains an archived directory structure which is treated as a path component all by itself.
BTW, I tend to believe that importing * is bad practice. It’s better if your code actually explicitly lists the classes it actually references.
More information than you wanted to know:
The metainformation in a .jar file is contained under the archive path “meta-inf”, and will include a file called “manifest.mf”, which basically lists global and optional per-file attributes of the archive. There is a java API for dealing with jar files, and many useful things can be included in the manifest, which can be manipulated through that API. When you reach the point of writing installers for your stuff, it’s a very useful mechanism.
An interesting feature of java is that you can actually provide your own classloader, and modify where classes and resources are found, and do so selectively for different class instances. The CLASSPATH mechanism we’ve been describing is how the default system classloader works. If you want to keep classes as blobs in a relational DB, for instance, you can write your own classloader. More commonly, classloaders are written for things like application servers to allow each application running under the server to have their own classpath without running into each other.
What he said. Pointing to the folder alone does you no good if the classes are in a jarfile. Pointing to the folder would only help if the classes have already been extracted from the jar, which wouldn’t (shouldn’t) be the situation here.
I would suggest you continue using JEdit for your basic tutorials, for the reason that you just saw. I have seen many programmers who can’t resolve difficult classpath issues because they’ve never had to resolve an easy classpath issue, thanks to the hand-holding of IDE’s. You’ve just learned something useful… I would suggest going to Eclipse only as a “cheat” when you can’t figure out how to do it by hand. Although in this case you might have had to debug the same problem in Eclipse, with the added headache of having to figure out where to set the classpath in the Eclipse GUI…
Full understanding of classpath issues will save you much trouble in the future. Keep at it. You should always be able to build from the command line. This way, you have far more options available for automated builds (using Ant or make) and you will better understand the subtleties of the classpath and the working directory.
For example, you will run into challenges when you try to reference resources such as images or properties files from either the classpath or the filesystem. You IDE can hide these problems until the moment you try to run your project outside the IDE and then you are stumped.
One particularly nasty problem is determining exactly which version of a file like “log4j.properties” is being used by your app. Is it the one in the working folder? The one in the same folder as the main class? The one at the root of the jar? The one in a specific folder in the jar?
It could be any one of these, depending on how the code is written, and it is not unusual for developers to simply copy the file to each of these and hope for the best without really understanding the inner workings.