I don't like setting CLASSPATH. CLASSPATH is a global variable and as such it is evil:

• If you modify it in one script, suddenly some java programs will stop working.
• If you put there the libraries for all the things which you run, and it gets cluttered.
• You get conflicts if two different applications use different versions of the same library.
• There is no performance gain as libraries in the CLASSPATH are not shared - just their name is shared.
• If you put the dot (.) or any other relative path in the CLASSPATH that means a different thing in each place - that will cause confusion, for sure.

Therefore the preferred way is to set the classpath per each run of the jvm, for example:

Copyjava -Xmx500m -cp ".:../somejar.jar:../mysql-connector-java-5.1.6-bin.jar"    "folder.subfolder../dit1/some.xml

If it gets long the standard procedure is to wrap it in a bash or batch script to save typing.

export CLASSPATH=/home/appnetix/LOG4J_HOME/log4j-1.2.16.jar

or, if you already have some classpath set

export CLASSPATH=$CLASSPATH:/home/appnetix/LOG4J_HOME/log4j-1.2.16.jar

and, if also you want to include current directory

export CLASSPATH=$CLASSPATH:/home/appnetix/LOG4J_HOME/log4j-1.2.16.jar:.

I'm not a Java programmer, so I don't know the correct value for CLASSPATH. But, you seem to. You can add it to ~/.bashrc like so:

CLASSPATH=/path/to/1:/path/to/2:/etc

The change will take effect globally the next time you log in. However, it will take effect immediately in new shells.

Additionally, if you want to set it for just one particular command, do this:

CLASSPATH=/something command-here arg1 arg2

A third way would be to create a wrapper script, which would be appropriate if you needed to set multiple variables or if you needed to determine appropriate values programmatically:

#!/bin/bash
export CLASSPATH=/something
export ANOTHER_ENV_Variable=foo

exec your_fancy_program "$@"

You have to supply the complete path after the parameter -jar. So for your example you have to call

java -jar /home/user/plantuml.jar -testdot

The $CLASSPATH is only evaluated to find additional files (classes/resources) but not the jar file defined in the command line.

export CLASSPATH=/your/stuff/

or preserving system wide settings:

export CLASSPATH=$CLASSPATH:/your/addition/

First, in general, setting the env var CLASSPATH usually causes more problems than it solves -- since not all app's want/need the same classpath, & often break when undesired or even unneeded jars are included in the classpath. A java app should only include the minimum number of jars it requires, no more, no less.

When you have specific, individual apps that do require that the classpath be set, then usually the command-line option is preferred: java -cp path1:path2:.... Desktop icons can have their command altered to include these options, or shell scripts can be modified to include these options.

That being said (and since there are always exceptions to the rule), then depending on the version of java (this requres java 6 or later), you can specify that a whole directory of jars be added to the classpath by adding a "*" at the end of a directory; e.g, the following:

 /dir1/foo.jar:/dir2/dir3:/dir5/dir6/*:etc...

Means:

• /dir1/foo.jar - (the single jar) will be added to the classpath;
• /dir2/dir3 - all un-jar'd classes in this directory will be added to the classpath (must be in proper package structure; e.g, com.my.Foo.class must be in /dir2/dir3/com/my/Foo.class)
• /dir5/dir6/* - all jars in this directory (i.e., /dir5/dir6/*.jar) will be added to the classpath. Note that this "*" isn't a wildcard (you can't use f*.jar or even *.jar); it's a special character indicating "add all jars"

In general, if you have to add a whole directory of jars to the application's classpath, the app was not bundled correctly. Rather, the app should have a manifest containing the list of jars it depends on. Or at the very least, only one jar should be added to your classpath, and that jar can have in its manifest the whole list of jars in some subdirectory.

I think you should not put any paths that a local to your home directory in a system wide file. I would leave /etc/environment well alone, unless you provide some changes, that are necessary or beneficial to all users. Put any changes to the CLASSPATH in your .bashrc in your home directory.

  CLASSPATH=$CLASSPATH:/home/foo:/home/foo/Java_code/my_code
  export CLASSPATH

This way you can source it and any newly started bash will have the settings right at once.

You need to use:

export CLASSPATH=/home/praveen/lib/commons-logging-1.0.4.jar:/home/praveen/lib/log4j-1.2.8.jar

rather than:

export CLASSPATH = /home/praveen/lib/commons-logging-1.0.4.jar: /home/praveen/lib/log4j-1.2.8.jar

You can't put spaces in between the variable name and the equals sign in shell scripting.

When programming in Java, you make other classes available to the class you are writing by putting something like this at the top of your source file:

import org.javaguy.coolframework.MyClass;

Or sometimes you 'bulk import' stuff by saying:

import org.javaguy.coolframework.*;

So later in your program when you say:

MyClass mine = new MyClass();

The Java Virtual Machine will know where to find your compiled class.

It would be impractical to have the VM look through every folder on your machine, so you have to provide the VM a list of places to look. This is done by putting folder and jar files on your classpath.

Before we talk about how the classpath is set, let's talk about .class files, packages, and .jar files.

First, let's suppose that MyClass is something you built as part of your project, and it is in a directory in your project called output. The .class file would be at output/org/javaguy/coolframework/MyClass.class (along with every other file in that package). In order to get to that file, your path would simply need to contain the folder 'output', not the whole package structure, since your import statement provides all that information to the VM.

Now let's suppose that you bundle CoolFramework up into a .jar file, and put that CoolFramework.jar into a lib directory in your project. You would now need to put lib/CoolFramework.jar into your classpath. The VM will look inside the jar file for the org/javaguy/coolframework part, and find your class.

So, classpaths contain:

• JAR files, and
• Paths to the top of package hierarchies.

How do you set your classpath?

The first way everyone seems to learn is with environment variables. On a unix machine, you can say something like:

export CLASSPATH=/home/myaccount/myproject/lib/CoolFramework.jar:/home/myaccount/myproject/output/

On a Windows machine you have to go to your environment settings and either add or modify the value that is already there.

The second way is to use the -cp parameter when starting Java, like this:

java -cp "/home/myaccount/myproject/lib/CoolFramework.jar:/home/myaccount/myproject/output/"  MyMainClass

A variant of this is the third way which is often done with a .sh or .bat file that calculates the classpath and passes it to Java via the -cp parameter.

There is a "gotcha" with all of the above. On most systems (Linux, Mac OS, UNIX, etc) the colon character (:) is the classpath separator. On Windows the separator is the semicolon (;)

So what's the best way to do it?

Setting stuff globally via environment variables is bad, generally for the same kinds of reasons that global variables are bad. You change the CLASSPATH environment variable so one program works, and you end up breaking another program.

The -cp is the way to go. I generally make sure my CLASSPATH environment variable is an empty string where I develop, whenever possible, so that I avoid global classpath issues (some tools aren't happy when the global classpath is empty though - I know of two common, mega-thousand dollar licensed J2EE and Java servers that have this kind of issue with their command-line tools).