The real use of classpath?

[S Chan]

Hi all,

Java newbie here. I am going to ask a newbie question here so please pardon me.

My question is - "what is the REAL use of classpath?" I want to clarify that I know how to use the -classpath parameter, so my question is not about 'what is classpath', but more of 'when and why use classpath?'

If I have some classes or packages, I would want to put inside my project workspace or in the lib folder of my projects so that they can be included during compile. Am I right on this? This is what I think a make-everthing-as-simple-as-possible approach it is, as far as I can reason myself. Why would I want to store some classes in some alien paths and include them using the -classpath parameters? Isn't that making things more complicated?

I have experience in working in a team project, and we used SVN to share source code. I understand that when there is some external libraries, it is wise to not put them in the SVN, but put them in the local storage in our individual working machines and link them with classpath... However, I find that this is quite troublesome when I set up the workspace for the first time or when I switch working environment/machines. I remember after getting the source from the SVN, the first successful compile is painful and taking a long time when there is no one telling me what external libraries are missing, what classpaths are to be set... I wonder how you experienced programmers "magically" know libraries are required when working on open/shared projects out there...

Another thing about classpath that leaves me puzzled is that, it is surely not distribution-friendly. Let's say I have made an executable Jar and distribute this to other people. I think double-clicking the Jar is the most intuitive way of starting the Jar for most people. If my Jar requires specific classpaths, I don't think there is an easy way to explain to them how to specify the classpaths, not to mention the "classpaths" may be different on different machines or the required classes/packages may not even exist on running machines... Or am I missing something??? Should I use something like Launch4J to ease this problem?

As a newbie, I have limited vision of what the "real projects" out there are like, so it would be good if you can show me some real world project example with explanation. Truly appreciated, really. This question is really bugging me since the first day of my Java learning.

S

[Jeff Verdegan]

S Chan wrote:My question is - "what is the REAL use of classpath?"

It is to provide a way to tell the JVM where to find classes and other resources, relative to arbitrary directories and/or jar files that serve as starting places (roots).

I wonder how you experienced programmers "magically" know libraries are required when working on open/shared projects out there...

We don't. Usually a given tool that we use comes with documentation telling us what it depends on. Or else the dependencies are just included with the download of that tool.

Another thing about classpath that leaves me puzzled is that, it is surely not distribution-friendly.

Quite the opposite. Once I know what jars are needed (and whatever tool or library or app I'm using should tell me what it needs), I can put those jars wherever I want, and then I just need to tell the JVM where I've put them. I don't have to worry about putting things in a specific location, which may not exist, or which I may not have access to, or which I may not want to use for this purpose.

Let's say I have made an executable Jar and distribute this to other people. I think double-clicking the Jar is the most intuitive way of starting the Jar for most people. If my Jar requires specific classpaths, I don't think there is an easy way to explain to them how to specify the classpaths,

Ah, that may be another story.

Java apps are not desktop apps, so the cases you're describing are in the minority. I'm not thoroughly familiar with the whole process of packaging a double-clickable jar, but I think that we either bundle the required jars inside our own, or else zip up those jars and our jar in a directory structure where we know where they are relative to our jar, and then specify their relative paths in the manifest. You'll have to look into that in more detail though, as I never produce desktop apps.

[Jesper de Jong]

S Chan wrote:My question is - "what is the REAL use of classpath?" I want to clarify that I know how to use the -classpath parameter, so my question is not about 'what is classpath', but more of 'when and why use classpath?'

You already know what the classpath is - it is the set of directories and JAR files that the Java runtime environment (and the Java compiler) looks in to find Java classes. That's all there is to it, there is no hidden meaning. You need to set the classpath so that all classes that are necessary for your program to run can be found. If a class cannot be found in any of the directories or JAR files in the classpath, you'll get a NoClassDefFoundError.

S Chan wrote:If I have some classes or packages, I would want to put inside my project workspace or in the lib folder of my projects so that they can be included during compile. Am I right on this? This is what I think a make-everthing-as-simple-as-possible approach it is, as far as I can reason myself. Why would I want to store some classes in some alien paths and include them using the -classpath parameters? Isn't that making things more complicated?

If Java would require you to have one directory, for example a "lib" folder, to find all its classes that might be a little simpler, but it would also be less flexible.

S Chan wrote:I have experience in working in a team project, and we used SVN to share source code. I understand that when there is some external libraries, it is wise to not put them in the SVN, but put them in the local storage in our individual working machines and link them with classpath... However, I find that this is quite troublesome when I set up the workspace for the first time or when I switch working environment/machines.

There are build tools such as Maven, Gradle and Ant to make things easier. A simple solution is to make a Windows batch file (*.bat) to set the classpath and run your program, and check this in in SVN so that not every developer has to find this out him- or herself.

S Chan wrote:Another thing about classpath that leaves me puzzled is that, it is surely not distribution-friendly. Let's say I have made an executable Jar and distribute this to other people. I think double-clicking the Jar is the most intuitive way of starting the Jar for most people. If my Jar requires specific classpaths, I don't think there is an easy way to explain to them how to specify the classpaths, not to mention the "classpaths" may be different on different machines or the required classes/packages may not even exist on running machines... Or am I missing something??? Should I use something like Launch4J to ease this problem?

With an executable jar, the classpath is set in the manifest file of the jar. The '-classpath' option and the CLASSPATH environment variable are ignored when you double-click an executable jar (or when you run it with '-jar'), so your users don't have to deal with this.

[Jelle Klap]

Managing the classpath and library dependencies, both internal and external, is not trivial for any real world project. Not at build time, and even less so at runtime. For managing dependencies at build time, I recommend looking into tools that support dependency management, like Apache Ivy or Apache Maven. Those can help you a great deal. Depending on how complex the application is, and to what extent you've modularized it, it might also pay to look into repository software like Artifactory or Nexus. That way you'll have a centralized repository for distributing internal dependecies that the dependency management tools can make use of.
Managing dependencies at runtime is trickier, and proper modularization will really help you there. You should probably have a look at deployment environments that offer a proper module system like OSGi. I believe JBoss 7 is OSGi compliant, but other servlet containers and application servers that use and support OSGi are still few and far between.

[Campbell Ritchie]

Not a beginning question: moving discussion.