Java package and class name confusions

Question

Suppose somewhere I import javax.servlet.http.HttpServlet.

My questions:

1. Does this mean: I could find a folder structure like javax/servlet/http somewhere and inside that HttpServlet.class file would be present?

2. If not, where exactly this class file could be found?

3. Does this mean: These are just nested namespaces with no relevance to folder structures?

4. Package name in the above mentioned import would be javax.servlet or javax.servlet.http? Probably both are packages and first one is super package of the later one?

5. How is this class file actually included? I've read import is not like c/c++ include.

Thanks.

Answer 1

Does this mean: I could find a folder structure like javax/servlet/http somewhere and inside that HttpServlet.class file would be present?

Yes (most likely packaged inside a jar file)

Package name in the above mentioned import would be

javax.servlet or javax.servlet.http? Probably both are packages and first one is super package of the later one?

Yes again

How is this class file actually included? I've read import is not like c/c++ include.

import packagename.classname and must be before class declaration ex:

import javax.servlet.http.HttpServlet;

Answer 2

1. Yes
2. It could also be in a jar file (in the javax/servlet/http directory)
3. No (see 1.)
4. More precisely, it's the parent package
5. Imports gives access to classes external to the file being compiled. The .class file contains references to the external classes it needs. Constants (final static variables) can be inlined (their values are inserted by the compiler in the code that use them).

Answer 3

1. yes

2. see 1.

3. see 1.

4. package name is javax.servlet.http

5. The classloader will locate the class (from its classpath) at runtime

Answer 4

1 - Does this mean: I could find a folder structure like javax/servlet/http somewhere and inside that HttpServlet.class file would be present?

In this case, probably not in the file system, per se. (This class is part of the J2SE runtime libraries.)

2 - If not, where exactly this class file could be found?

In a JAR file that is on your JVM's classpath or bootclasspath. The JAR file is an archive containing .class files and other resources. The pathname of the class within the JAR file would be /javax/servlet/http/HttpServlet.class. (In this case the class in the rt.jar file.)

3 - Does this mean: These are just nested namespaces with no relevance to folder structures?

No. If you have file system folders on your classpath, they may be searched to find classes, before or after JAR files, depending on where on the classpath they are. The classpath effectively overlays the namespaces. Namespaces of JAR files can overlay namespaces of file system folders, and vice versa, depending on the effective classpath.

4 - Package name in the above mentioned import would be javax.servlet or javax.servlet.http?

javax.servlet.http

4 continued - Probably both are packages and first one is super package of the later one?

Both are packages, but there is no such thing as a "super package" in Java. As far as the Java language is concerned javax.servlet and javax.servlet.http are unrelated packages. Some people might say that javax.servlet is the parent package of javax.servlet.http, but this statement has no intrinsic meaning from the perspective of the Java language. The apparent parent-child relationship is purely conventional.

5 - How is this class file actually included? I've read import is not like C/C++ include.

The class file is not "included" in any sense. A Java import is little more than a shorthand that allows you to refer to the imported name without qualifying it with its full package name.

Answer 5

A fully qualified classname consists of one package name (the namespace) and the classname. Let's take a simple example:

 java.lang.Object

The (simple) classname is Object, the packagename is java.lang. There is a practical recommendation in the JLS to construct a packagename with identifiers separated by dots. This is practical because this way we can map a packagename to a folder structure. The packagename from the above example is mapped to ./java/lang, the fully qualified classname to a file ./java/lang/Object.class for the binary and ./java/lang/Object.java for the source file.

This makes it pretty easy for a classloader to find classfiles on the filesystem. The classloader simply evaluates the namespace (packagename) for the folder and the simple classname for the name of the classfile.

A common misunderstanding is thinking, packagenames are somewhat hierarchical. This is not true. There is no relation between packages com.example.bean and com.example.bean.impl. The first one is not a sort of parent package.

Answer 6

For a slightly higher-level answer: the package name is a way of creating a namespace - there is no hierarchy of namespaces. However, the actual class (using the fully-qualified name, e.g. javax.servlet.http.HttpServlet) needs to be loaded by a ClassLoader.

The bog-standard ClassLoader that is used by the JVM is an instance of java.net.URLClassLoader (well, a subclass). This can look up classes given a starting point of either a directory or a JAR file. The package name is the overlaid over the filesystem structure to get the location of the class.

There are other ClassLoaders out there - most also follow this convention to some degree, but it is just a convention. ClassLoaders can load classes however they choose, including dynamically generating them.

For javax.servlet.http.HttpServlet, you'll probably find the class file inside a jar called something like servlet.jar or j2ee.jar. There's a neat utility called JFind that will help you locate where a class can be found - it's also usually pretty easy within an IDE as well.

For question 5 - as others have mentioned, the import statement simply brings the imported class or package into the local namespace, allowing you to use the convenient short name of HttpServlet instead of using the long name of javax.servlet.http.HttpServlet everytime you need to refer to it. You can program in Java and never use an import statement if you like, though people will probably look at you oddly.