For instance
import org.apache.nutch.plugin.Extension,
though used many times,
I've no much idea what is done essentially.
EDIT: Is org.apache.nutch.plugin
essentially 4 directories or fewer than 4 like a directory named org.apache
?
Import in Java does not work at all, as it is evaluated at compile time only. (Treat it as shortcuts so you do not have to write fully qualified class names). At runtime there is no import at all, just FQCNs. At runtime it is necessary that all classes you have referenced can be found by classloaders.
In Java, the import statement is written directly after the package statement (if it exists) and before the class definition.
I think the question you might be trying to ask is, "What are packages in Java, and how does the import
keyword relate to them?". Your confusion about directory structures might stem from the fact that some other languages have include
directives that use file names to literally include the contents of the specified file in your source code at compile time. C/C++ are examples of languages that use this type of include
directive. Java's import
keyword does not work this way. As others have said, the import
keyword is simply a shorthand way to reference one or more classes in a package. The real work is done by the Java Virtual Machine's class loader (details below).
Let's start with the definition of a "Java package", as described in the Wikipedia article:
A Java package is a mechanism for organizing Java classes into namespaces similar to the modules of Modula. Java packages can be stored in compressed files called JAR files, allowing classes to download faster as a group rather than one at a time. Programmers also typically use packages to organize classes belonging to the same category or providing similar functionality.
In Java, source code files for classes are in fact organized by directories, but the method by which the Java Virtual Machine (JVM) locates the classes is different from languages like C/C++.
Suppose in your source code you have a package named "com.foo.bar", and within that package you have a class named "MyClass". At compile time, the location of that class's source code in the file system must be {source}/com/foo/bar/MyClass.java
, where {source}
is the root of the source tree you are compiling.
One difference between Java and languages like C/C++ is the concept of a class loader. In fact, the concept of a class loader is a key part of the Java Virtual Machine's architecture. The job of the class loader is to locate and load any class
files your program needs. The "primordial" or "default" Java class loader is usually provided by the JVM. It is a regular class of type ClassLoader
, and contains a method called loadClass()
with the following definition:
// Loads the class with the specified name. // Example: loadClass("org.apache.nutch.plugin.Extension") Class loadClass(String name)
This loadClass()
method will attempt to locate the class
file for the class with given name, and it produces a Class
object which has a newInstance()
method capable of instantiating the class.
Where does the class loader search for the class
file? In the JVM's class path. The class path is simply a list of locations where class
files can be found. These locations can be directories containing class
files. It can even contain jar
files, which can themselves contain even more class
files. The default class loader is capable of looking inside these jar
files to search for class
files. As a side note, you could implement your own class loader to, for example, allow network locations (or any other location) to be searched for class
files.
So, now we know that whether or not "com.foo.bar.MyClass" is in a class
file in your own source tree or a class
file inside a jar
file somewhere in your class path, the class loader will find it for you, if it exists. If it does not exist, you will get a ClassNotFoundException
.
And now to address the import
keyword: I will reference the following example:
import com.foo.bar.MyClass; ... public void someFunction() { MyClass obj1 = new MyClass(); org.blah.MyClass obj2 = new org.blah.MyClass("some string argument"); }
The first line is simply a way to tell the compiler "Whenever you see a variable declared simply as type MyClass
, assume I mean com.foo.bar.MyClass
. That is what's happening in the case of obj1
. In the case of obj2
, you are explicitly telling the compiler "I don't want the class com.foo.bar.MyClass
, I actually want org.blah.MyClass
". So the import
keyword is just a simple way of cutting down on the amount of typing programmers have to do in order to use other classes. All of the interesting stuff is done in the JVM's class loader.
For more information about exactly what the class loader does, I recommend reading an article called The Basics of Java Class Loaders
All it's doing is saving you typing. Instead of having to type "org.apache.nutch.plugin.Extension" every time you want to use it, the import allows you to refer to it by its short name, "Extension".
Don't be confused by the word "import" - it's not loading the .class file or anything like that. The class loader will search for it on the CLASSPATH and load it into perm space the first time your code requires it.
UPDATE: As a developer you have to know that packages are associated with directories. If you create a package "com.foo.bar.baz" in your .java file, it'll have to be stored in a directory com/foo/bar/baz.
But when you download a JAR file, like that Apache Nutch library, there are no directories involved from your point of view. The person who created the JAR had to zip up the proper directory structure, which you can see as the path to the .class file if you open the JAR using WinZip. You just have to put that JAR in the CLASSPATH for your app when you compile and run.
Imports are just hints to the compiler telling him how to figure out the full name of classes.
So if you have "import java.util.*;" and in your code you are doing something like "new ArrayList()", when the compiler processes this expression it first needs to find the fully qualified name of the type ArrayList. It does so by going thru the list of imports and appending ArrayList to each import. Specifically, when it appends ArrayList to java.util it get the FQN java.util.ArrayList. It then looks up this FQN in its class-path. If it finds a class with such a name then it knows that java.util.ArrayList is the correct name.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With