CODEWITHSUNDEEP
javamavenimportjarhttpclient
Juan
Juan

Reputation: 532

Still having issues with java libraries

I never truly understood java libraries and would love if someone could clarify my understanding:

  1. When I need a package, which doesn't come by default with java, then I google it and download the binaries. i.e. "HttpClient" then I download httpcomponents-client-4.2.2-bin.zip from apache.org
  2. I first need to import the .zip file to netbeans, and then use the import command (which normally is automatically suggested).

I still have some questions/problems.

HttpClient class seems to be part of the apache client library, but I am told to import sun.net.www.http.HttpClient why? (even if i do it doesn't solve rest of the problems)

Then trying to use HttpClient httpclient = new DefaultHttpClient(); says that DefaultHttpClient symbol cannot be found, but the library has already been added to Netbeans.

Looking at this similar example http://www.vogella.com/articles/ApacheHttpClient/article.html some of the imports don't come with the package I downloaded.

This happens pretty often to me, and sometimes I manage to fix it without really understanding. Atm I am trying to implement this answer https://stackoverflow.com/a/3325065/960086

Upvotes: 1

Views: 628

Answers (1)

Nick Holt
Nick Holt

Reputation: 34311

OK, there's a few things you need to understand with regards to how the JVM is able to create instances of classes and I'll start at the bottom.

When an JVM starts it needs to load the classes that will be used to run the application. To do this there's 3 class-loaders in play - the bootstrap class-loader, the extensions class-loader and the system class-loader. The first 2 load classes from jar files in the $JAVA_HOME/lib and $JAVA_HOME/lib/ext respectively. They're basically what's needed to get the JVM running - don't worry about those for now. The third class-loader, the system class-loader, is what you're interested in. It's this system class-loader that uses the classpath to find the classes that you are adding to the JVM to form your application.

There's much more to class-loaders but that will do for now.

So the system class-loader uses the classpath to load classes. In its simplest form the classpath is nothing more than a reference to the directory that the Java compiler output the classes it created to. Within that directory you will find a hierarchy of directories that represent the package structure you used when you wrote classes (the package declaration at the top of the .java file used to organize your classes within the context of your application) and the .class files that contain the compiled classes. When a class is needed by the JVM, the system class-loader parses the directory structure representing the package and loads the class (or throws a ClassNotFoundException if it cannot find it).

Now, one of Java's strengths is the sheer number of 3rd party libraries available. Obviously sharing code by copying directories about isn't going to work and so Java Archive or JAR file is used. A JAR is nothing more than a zip file with a couple of standard directories plus the same directories that represent package structure and the .class files that I mentioned previously. Of course it picks up the extension .jar but any tool capable of opening a zip file will open a JAR. To use a JAR you simply add it to your classpath just as you would a directory and as with the directory, the system class-loader will parse the structure it contains to load classes as need be.

That said, you rarely download just a JAR when you decide to use a 3rd party library, as in your case with HttpClient. Obviously there's more than just the classes to any 3rd party library and most will include documentation, examples and maybe even the source code. However to use the 3rd party library the process is the same, you need to extract the JAR containing the classes you want to use and add that JAR to your classpath.

That's almost the full story - as the number of 3rd party libraries being used by typical applications grew so did the problem of managing these libraries and so Ant with Ivy and more recently Maven became popular. In addition to their build capabilities both provide a way to declare the 3rd party libraries that your application depends on and streamline the process of downloading those libraries and adding them to you classpath. But what they are doing is just the same as if you were to download libraries and add the to the classpath manually.

Upvotes: 4

Related Questions