Originally Posted by gsl
In a proper Java setup (which I assume yours is) you should never need to include the core jars on the classpath. The javac compiler should know how to find all the jars in the jdk*/jre/lib and jdk*/lib directories. Your classpath should only need to include your own Java sources and any external (non-core) jars you might be using.
No it doesn't, really. More specifically you have to tell javac where it can find the classes. The location of rt.jar is not standard and depending on the jdk version. This said, I would have been nice if Debian at the installation of the JDK would have set the classpath, but it had not.
Some more observations:
I settled for using ant tool to compile and build this source tree. (http://ant.apache.org/
). It was quite straightforward (well, kind of), but using the example build.xml got me going very quickly.
Once I got the hang of looking up jars on the internet, I was able to find about 10 more jar files which had to be added to the libraries. It is not difficult, but you have to know what you are looking for. If you are totally blank, it is overwhelming, but after that it is OK. BTW, CLASSPATH is not
a path, it has to be a list of all JAR files which you want to include in the compilation, so youhave to specify /usr/share/jdk6/*.jar and not /usr/share/jdk6. CLASSPATH gets very large if you have enough classes!
In the source tree there was a part which interfaced with SQL and had a number of classes derived from java.sql.preparedstatement and java.sql.callablestatement, which were TraceCallableStatement, TraceConnection, TracePreparedStatement, and TraceStatement. There were a huge number of abstract methods which were not overrided in these derived classes. Perhaps the developer at that time compiled against JDK 1.0 or 1.1. I went as low as 1.2, but there was still the problem of these abstract methods. I ended up to add the methods for each not overrided abstract class, which eventually were over one hundred. (Yes, I learned that Java allows to define multiple methods with different parameter lists, and they all
have to be overrided)
The problem here was that Javac would only give a few error messages per file, I could not figure out why only so few. I have compiled at least a hundred times, and every time 3 or 4 errors would be stated. Well, after twenty times solving errors and adding methods from Preparedstatement and CallableStatement and TraceCallableStatement, TraceConnection, TracePreparedStatement, and TraceStatement the Traces, Statement and Prepareds became pretty big mess, especially if you take into account that in one object setNClob (int i, Clob x) had to be added in 4 variation and in one other setNClob (String i, Clob x) and then getNClob oh no, it was setBlob, no setNBlob, oh that was TraceCallableStatement no, that was setBlob, no that was setBlob (int i, Reader x), no that was getClob or was it getClob, no that was in TracePreparedstatment...
WHAT DID I DO WRONG HERE AND WHY WAS I FOUR DAYS ADDING THOSE METHODS TO THE CLASSES?
Eventually I had all methods added, and only THEN
the compiler started to complain about missing return statements, which I solved my called the ancestor, and when that was solved, I had to add the ThrowSQLExceptions that I forgot and when that was finished the compiler complained about the function isWrapperFor which was not overrided and unWrap alike but those were no part of Preparedstatement and CallableStatement so I had to get them from Wrapper and when that was finished they did not throw SQLExceptions but something else and when I fixed that the compiler complained that some abstract methods were not overridden, and finally, yes, I have to admit, I forgot a semicolon.
I think it is better to get 400 compile errors at once than a hundred times four...
The good news is that suddenly, in the 123rd run ant would tell "Build completed succesfully" Just out of the blue. I had been down to 1 error many times before, but the next time it would give me another 3 or 4. This was soooo sweet. Ant let me create the jar file as well, even when compiling going up to jdk5 again, and as unbelievable as it is, the JAR file could actually be run, and even produced the same program as I had downloaded and run before.
Now ahead to adding those 3 lines...