XML Serializer....!

Question

Hi guys...!
I'm writting a program in Java that prints out the content of an XML file. I imported different classes, but some of the class that I imported do not work. I don't know why.
Since some of the classes do not work, I can't compile my java program.
Here are the classes that give me error....
import org.apache.xml.serialize; .============> ERROR
import org.apache.xml.serialize.OutputFormat; ===========> ERROR
import org.apache.xml.serialize.Serializer; ===============>ERROR
import org.apache.xml.serialize.DOMSerializer; ===========>ERROR
import org.apache.xml.serialize.SerializerFactory; =========>ERROR
import org.apache.xml.serialize.XMLSerializer; ===========>ERROR
and here are the codes that don't compile within my java program..
OutputFormat format = new OutputFormat (doc); ==========>ERROR
StringWriter stringOut = new StringWriter ();
XMLSerializer serial = new XMLSerializer (stringOut, format); ==>ERROR
serial.serialize(doc);
System.out.println(stringOut.toString());
Can you guys please help me finding out what is going on in my codes????
Any help will be appreciated...
Thanks...
--- Spirit_Away

Answer 1

While this problem is simple to someone who's battled classpath problems many, many times, it's frustrating as hell to those who haven't.
You have a run time classpath and a compile time classpath.
A compile-time classpath is used by javac or your IDE to find the classes that you're referencing when your code is compiled.
If you compile a simple class from the command-line with javac, you'd use the -classpath option to specify to the Java compiler where it needs to look to find the classes you've referenced in your class.
If you use an IDE, you need to tell your IDE where to find the classes you're referencing in your class -- each IDE does this slightly differently. In Eclipse, it's referred to as your "build path" and it contains either folders of classes or JAR files. As you add JARs or folders of classes to your build path, you make those classes available at compile time to your classes that you're compiling.
If you manage to include those properly, you'll end up with YourClass.class -- a compiled version of your class.
Now, to invoke your class, you need to make sure that the same classes/JARs that you put in your build path are also available to the Java Virtual Machine when you execute your class -- this is done through the CLI with the -classpath option to the java command.
There are a few ways to get those classes in your runtime classpath.
You can:
a) set an environment variable called CLASSPATH which includes the JARs/class folders so that every time the jvm is invoked (e.g. prompt$ java MyClass ) those classes are included in the runtime classpath
b) throw all of your dependent JARs/classes into $JAVA_HOME/jre/lib/ext so that anytime anyone on that machine executes the JVM, those dependent classes are included in the system-wide classpath
c) include the JARs/class folders in the classpath argument when invoking the JVM (e.g. prompt$ java -classpath=".:HelperClasses.jar" MyClass )
Personally, I find a) and b) to be bad ideas. Especially if you build Java apps to distribute. It makes it far too easy to forget to include dependent JARs and classes, because while they work for you on your system, they won't work on another system, unless that system also has the dependent JARs/classes installed properly in the classpath -- either for that system or the executing user.
Another drawback is that by silently including classes in your runtime classpath, you can unknowingly create class conflicts as you can end up accidentally loading multiple copies of the same class -- sometimes different versions -- and you don't realize that the one you THINK is executing is actually not the one that ACTUALLY is.
For this reason, I strongly suggest keeping your system class path and CLASSPATH variables empty and using option C -- until you have a strong handle on how classpaths work.
Some people will throw all of their dependent classes/jar files into $JAVA_HOME/jre/lib/ext to avoid having to add them to their runtime classpath.
In your case, you'd need to include the JAR files as options to the -classpath argument when you invoke the JVM.