java.ext.dirs
. For example:java -Djava.ext.dirs=c:\mylibs mypackage.MyClass
c:\mylibs
.
Note that to achieve this effect for compilation, you needjavac -extdirs c:\mylibs (rest of normal javac command
line)
By default, Java will use the jre/lib/ext
directory of
the currently running JRE. (Note that some VM installers don't create
this directory, so you may need to add it by hand.) The one problem
with this is that on Windows, you may not be using the JRE you think
you are... When the JDK is installed, 2 JREs are installed -
by default, they are in c:\jdk1.3
and
c:\Program Files\JavaSoft\JRE\1.3
(that's for 1.3, of
course). A link to the latter JRE is also placed in the
c:\WINNT\system32
directory (or the equivalent,
depending on which version of Windows you're using). This means that
unless you're careful, you'll be using a different JRE for compiling
code than for running it. This means that you'll either have to put
your jar files in two places (which is a maintenance nightmare) or
make sure you use the JDK version for both compiling and running. I
do this by putting c:\jdk1.3\bin
right at the start
of my path environment variable, before any system directories.
Alternatively you could rename the java.exe
in the
system32
directory, for example. Note that the place to
put jar files for the JDK (for both compiling and running) is
c:\jdk1.3\jre\lib\ext
, not
c:\jdk1.3\lib\ext
.
The other slight wrinkle with the extensions mechanism is obvious
but can still catch everyone out: if you have multiple versions of
the same classes in your extensions directory, you're asking for
trouble. For instance, having both jsdk.jar
from the servlet
2.0 development kit and servlet.jar
from the servlet
2.2 development kit in the extensions directory is just asking for
trouble. Similarly some XML parsers/factories don't like to mix and
match - it's best to make sure you know which you need and only have
that available.
Back to the main page.