Here are some questions about setting the CLASSPATH in IntelliJ:
Adding Jar files to IntellijIdea classpath
how to add directory to classpath in an application run profile in intellij idea?
Java - setting classpath
Most of the answers involve changing settings in the Project Settings -> Modules -> Sources or -> Dependencies pages. But the word "CLASSPATH" isn't actually on those pages.
For example, the -> Dependencies page lets one explicitly set a place to find other .class files or .jar files. But no "CLASSPATH" anywhere.
Also, setting a location in the -> Sources page seems to indicate what the directory tree for
the .class root should look like, but the actual location is actually set in the Project Settings -> Project -> Project Compiler Output field, again without the word "CLASSPATH".
Is JetBrains trying to hide this word for some reason (eg. it's meant to be a multi-language IDE)? Is there some place to explicitly set the CLASSPATH other than an env variable?
As you say, the CLASSPATH is an environment variable, so it would affect all applications referencing that variable:
The class search path (more commonly known by the shorter name, "class
path") can be set using either the -classpath option when calling a
JDK tool (the preferred method) or by setting the CLASSPATH
environment variable. The -classpath option is preferred because you
can set it individually for each application without affecting other
applications and without other applications modifying its value.
Source: http://docs.oracle.com/javase/7/docs/technotes/tools/windows/classpath.html
You can also use the -classpath option when running your application, which would not affect other Java applications running on your system.
IntelliJ will construct your classpath to include both your application and any dependencies (whether folders or Jars etc.) and passes that to the JVM when you run your application. The IntelliJ GUI does refer to your explicit "Dependencies" and let you edit them. Your application build path would need to contain those dependencies and all of your application code, so it makes sense to include that implicitly.
If you were to use a lot of libraries, your classpath could become very long - having to maintain the list of locations in the class search path manually would be time consuming and (human) error prone - a typo on a folder name and it won't compile / run - so it assumes the task for you.
You'll probably find your IDE passes a number of other arguments to the JVM on your behalf (heap size, GC, JMX extensions and so on) - but that's part of what your IDE is for. Sure, we could invoke things like version control ourselves from the command-line, but why forgo the help? Your IDE isn't trying to "hide" anything from you, it's (hopefully) providing a more intuitive interface for many common development tasks.
CLASSPATH happens to be the name of the environment variable used automatically by Java.
It's generally considered a better option to use the -cp argument to explicitly set the classpath rather than fighting with CLASSPATH conflicts since it's process-wide.
It's not trying to "hide" it at all; there's just no reason to use it.
Related
My knowledge of ClassLoader in Java at the moment, is a little obscure. That's because I have not found any good documentation geared towards beginner of CLassLoader, thus far. And what I am looking for exactly is in relation to Maven. With disclaimer stated, let me get into my question.
I am writing a Spring MVC application, and I decided to look into how the Dependencies - Jars and classes are loaded using ClassLoader. And what I found is according to the documentation of ClassLoader, classes in Jar are loaded from CLASSPATH, and I can see them under the .m2/repository directory, but CLASSPATH does not yield anything, it's practically empty.
Can somebody please explain to me, how the classes from JAR are loaded into JVM Memory using ClassLoader using Maven, if the CLASSPATH is empty.
Thanks
You're confusing a few things.
The ClassLoader
The ClassLoader is a runtime concept. Maven is a compile time concept. Therefore, one has nothing whatsoever to do with the other. Maven and ClassLoaders do not interact. At all.
When you start a basic java app (java -jar foo.jar or java com.foo.MainClass), you get 2 classloaders. One loader will load system stuff: java.lang.String, for example. the executable itself 'just knows' how to do this (you don't need to configure PATH, CLASSPATH or JAVA_HOME - it just works); up to java 8, it finds rt.jar automatically, which contains String.class and other core classes. Starting from java 11, it finds the jmod files in your java distro.
Then, once the VM has 'booted up', the VM makes another classloader, also based on its built-in stuff: The app classloader.
This one uses 'the classpath'. The source of this depends on how you ran your java app:
java -jar somejar.jar
The source of the classpath in this case is the Class-Path: line in the jar's manifest (the file at META-INF/MANIFEST.MF). And nothing else - the CLASSPATH environment variable, and any -cp or -classpath options are entirely ignored.
java -cp a.jar:b.jar:. com.foo.ClassName
Note that -cp is short for -classpath (they mean the same thing): Here, the classpath is taken to be all the files and directories listed (on windows, use ; as separator instead), and classes are loaded from there. Including com.foo.ClassName itself.
java com.foo.ClassName
If you don't explicitly specify a -cp param, then the environment var CLASSPATH is used. You don't want this though. Always specify classpath.
That's runtime - maven has nothing whatsoever to do with this.
Make your own
You can make your own ClassLoader; the abstraction is such that all it needs to be able to do, is turn a resource name into bytes. That's it. You can make a ClassLoader (literally! public class MyLoader extends java.lang.ClassLoader { ... }) that.. loads data from a network, or generates it on the fly, or fetches it from an encrypted data store. Whatever you like.
Using custom classloaders like this is a solution for finding classes in 'weird' places (not jar files or directories), as well as a mechanism to allow java to 'reload classes' on the fly - very useful when developing, say, web apps, without the use of a hot-code-replacing debugger like eclipse has. ClassLoaders is a mechanism whereby a web server can have the following feature: "I load jars or wars from a certain preconfigured directory.. and if you replace the jar, I will see it and start using the new one".
Writing your own ClassLoader is bordering on rocket science and not usually required unless you're, say, writing an app server. Not a common job.
Maven
To compile source code, the compiler must know the methods and fields and such of all the types you refer. You can't compile "Hello".toLowerCase(); if the compiler doesn't know what String contains.
Thus, compilers also have this notion of 'I need to find classes'. But This is not called class loading, and notably, maven never loads any classes. If it did, any static initializers in any class would run, and mess up your compile. Maven instead just inspects the class file, never letting the VM actually load it, to know what kind of methods and fields and the like are on offer.
java.lang.ClassLoader plays no part in this.
javac itself has a -classpath option as well. So does maven, really.
Maven constructs the classpath automatically, by putting the stuff it already compiled for you (e.g. when compiling the stuff in src/test/java, the compiled stuff from src/main/java is on the classpath), as well as all the dependencies. How? Well, does it matter? Maven does. It constructs a large list of dirs and jars and passes it to javac via the -classpath parameter.
I would like to use the library "Lucene" with java. The instructions to use it tell me I have to put the jar's cointaining the classes inside the CLASSPATH.
The CLASSPATH is the directory containing all the default classes of Java? Or the directory of my specific project? I'm using Eclipse as IDE.
Really confused about that! Thank you.
USEFUL SOLUTION: http://www.avajava.com/tutorials/lessons/how-do-i-use-lucene-to-index-and-search-text-files.html
The Classpath is a collection of directories and JAR files inside which the Java runtime will look for classes.
It can be configured via an environment variable named CLASSPATH, but this usage is not recommended, as it tends to constantly result in problems.
The preferred way to configure the classpath when running a Java program is to pass it via the -cp command line switch when you start the Java interpreter. Usually you write a shell script so you don't have to type it out every time.
If your issue is with using the classes inside the IDE where you write your code, then it depends of course on the IDE. For eclipse, the "Java Build Path" tab of the project properties is where you configure the classpath.
Since jars like servlet.jar are usually not downloaded on their own, but rather come part of tomcat/lib folder, should I just add an entry to them in the classpath? Is that the common practice?
I use Ubuntu.
You only need to reference them yourself when you want to compile servlet classes. How to do that depends in turn on the tools used for compilation.
If you're using plain javac, then you could reference them in %CLASSPATH%. But even then, that's considered a poor practice since that would potentially pollute the default classpath of all other Java compilations/applications. Rather write a shell file which sets the classpath right on the current execution environment by utilizing the -cp attribute of javac command.
If you're using a bit decent IDE like Eclipse/Netbeans, then you should just integrate the server in the IDE and associate the project with it. The IDE will then take care about setting the buildpath right. You don't need to set any environment variables then.
You do not need to reference them when you want to run them. The servletcontainer will take care about it by itself.
See also:
How do I import Servlet API in Eclipse?
If you are running a web application on Tomcat then the servlet-api.jar is in the classpath.
Okay. So here's my question: I am making a data parser in Clojure. One part of my program is that it has to be able to graph the data. I figure, I'll use jFreeChart. However, I have absolutely NO IDEA how to include stuff in JAR files. What I mean is: if I have a app.jar file in my classpath, I don't seem to be able to do:
import app.thing.thing2
without changing the classpath to be inside the jar file.
The idea here is that I don't think I can change my classpath since I need to set it to run Clojure (Or do I?). The global classpath is currently /usr/share/java.
And please don't ask me to use Maven, Ant or any project-building tool unless it is the only way to do this. This is a script for personal use that doesn't need or want a whole lot of overhead.
I wonder if I should just unpack every JAR file, so that I can reference the directory structure? Is this bad?
Let me know if you need any clarifications!
The content of the (Java) CLASSPATH environment variable is available to Clojure so if you add your jar to the global classpath before to run Clojure, you'll "see" it:
export CLASSPATH=/path/to/jfreechart.jar:$CLASSPATH
But, in my opinion, this is not the "clean" way to add a jar to Clojure's classpath (because this makes the library visible to any Java program and may not be desired). Instead, you should use the CLOJURE_EXT environment variable. This is how this variable is documented:
# CLOJURE_EXT The path to a directory containing (either directly or as
# symbolic links) jar files and/or directories whose paths
# should be in Clojure's classpath. The value of the
# CLASSPATH environment variable for Clojure will be a list
# of these paths followed by the previous value of CLASSPATH
# (if any).
On my system, it is defined as below:
export CLOJURE_EXT=~/.clojure
So, to add jfreechart.jar (or any other library) to Clojures's classpath, copy it (or add a symlink pointing to it) in the directory defined in the CLOJURE_EXT variable.
And by the way (I'm sorry but your question is not that clear), if you want to bundle some Java classes into a jar, the command is something like that:
$ jar cf myjarfile *.class
You'll find documentation of jar - the Java Archive Tool - here.
I completely respect your desire not to use a project management tool, though I just spent longer typing this sentence than it takes to set up leiningen. For your one-off script any tool is going to be overkill and Pascal Thivent's answer covers this very well. For people reading this question who perhaps want to produce a jar file, or easily load their Clojure into emacs/slime-swank I cant recommend leiningen too strongly.
If you going to basics you can inline your classpath to include the hardcoded location of your jars, so if you on windows it will look something like
java -cp .;%CLASSPATH%;C:/here/it/is/foo.jar com.foo.MyClass
Not sure how clojure is run, but don't you just add the jar file to the classpath?
i.e.
/usr/share/java:/home/user/myjarfile.jar
I have a Java program that is calling C code through JNI that I'm attempting to run on Linux. The external code consists of two .so files: one for the JNI bindings (built with swig) and the other with the actual functions. I have the two libraries in the same directory and LD_LIBRARY_PATH is set correctly. ldd reports no problems when running from the command line, but when I set the LD_LIBRARY_PATH to the same value in the "run configurations" dialog in the Eclipse editor and attempt to execute the program, it gets the following error:
java.lang.UnsatisfiedLinkError: [path to libraries]/[JNI binding library].so: [actual code library].so: cannot open shared object file: No such file or directory
This leads me to believe that the JNI wrapper library is loaded successfully, but there is a failure when that library attempts to load the library containing the actual code. Is there any way to debug this further?
I will further note that this problem is happening in the eclipse editor itself and that I haven't attempted to package the code into a jar and run it within a free-standing jvm instance.
I think the issue is with the call to System.loadLibrary(String) and using LD_LIBRARY_PATH. Using loadLibrary("foo") will look in your java.library.path for something named libfoo.so. If nothing named libfoo.so is found you will get this error.
Now if you just set up the LD_LIBRARY_PATH, the native symbols you want will automatically be picked up by the linker, so you don't need to set up -Djava.library.path.
In my experience with swig in the gdal project, this error is actually harmless and since the LD_LIBRARY_PATH is set up, this will work fine.
I would recommend using -Djava.library.path and calling loadLibrary explitly, the reason being that if you ever decide to deploy your app with webstart, you will explicitly need to call loadLibrary to get your native libs picked up.
When I use eclipse I follow the instructions that Daff gave where you edit the native library under the jar in the Libraries tab in the Build Path. Just to mention again, this just sets java.library.path under the covers.
It may be that you just have to find the right place on the run config dialog to put the -Djava.library.path=... option. Offhand I think you want -D defines in the "vm arguments" on the arguments tab, whereas if you want to define LD_LIBRARY_PATH that goes on the environment tab. Eclipse will merrily let you put things in places where they won't mean what you think they mean. Anyway, I've used libraries this way before and if I get a chance I will look up what I did and edit my answer here.
Another thing to try is to play with LD_DEBUG. You can set the environment variable LD_DEBUG to various things (try ALL), and then the linux loader will divulge all sorts of useful information about what an application is trying to load, where it's looking for things, etc. Of course, this pre-supposes you launch eclipse from a command line, so you can both set the env vars and see the loader diagnostics; but as far as the system is concerned, when you run your app from inside eclipse, your app is just something eclipse is doing, so any library loading behavior can be seen in this way.
You could try -Djava.library.path=actual.so in command line parameters perhaps?
On windows, I had similar problems with a 3rd party library, which used a JNI wrapper DLL for its DLLs. My project had the DLL in the lib directory so I added lib to the PATH (e.g. PATH=%PATH%;./lib environment variable and everything started working.
As far as I know the Eclipse doesn't use the LD_LIBRARY_PATH.
The easiest way to set up the right native library path is to go to
Project properties -> Java Build Path -> Libraries
Then expand either the JRE System Library entry or (if available) the
Jar File that uses you native Library,
choose "Native Library Location" then click "Edit..." and choose the folder your libraries are in. Actually it does set the -Djava.library.path variable so you have to include this in your command line if you start your program from outside eclipse.
Are there any other libraries that your two libraries depend on? If so, you need to make sure they are also accessible to the JVM.
Be aware, manually setting "-Djava.library.path" seems to erase the default library path.
So with the following code:
public class LibTest {
public static void main(String[] args) {
String property = System.getProperty("java.library.path");
StringTokenizer parser = new StringTokenizer(property, ":");
while (parser.hasMoreTokens()) {
System.err.println(parser.nextToken());
}
}
}
Launched from eclipse with Java 1.6.0_14 outputs:
/opt/java/jre/lib/i386/client
/opt/java/jre/lib/i386
/opt/java/jre/../lib/i386
/opt/java/jre/lib/i386/client
/opt/java/jre/lib/i386
/usr/lib/xulrunner-devel-1.9.0.11
/usr/lib/xulrunner-devel-1.9.0.11
/usr/java/packages/lib/i386
/lib
/usr/lib
But when I set the JVM arg "-Djava.library.path=/tmp/" I only get:
/tmp/
If you are manually setting java.library.path this may explain why ldd works from the command line but your .so does not from eclipse/java.
You can try not setting java.library.path and use System.load with the absolute path to your library instead of calling System.loadLibrary. This may allow the JVM to find your .so and still use the default path when searching for its dependencies.
Of course, if this is no use then you can also try turning on jni debug output with "-verbose:jni" on the command line. This may give you some clues to the problem.
Yes the LD_LIBRARY_PATH worked for me
Adding this answer may be it can be useful In AIX Machines we need to setup LIBPATH environment variable instead of LD_LIBRARY_PATH.