How Does Java Decide When to Import

How does Java decide when to import?

There is an implicit import of java.lang.*.

From the Java specification:

A compilation unit automatically has access to all types declared in its package and also automatically imports all of the public types declared in the predefined package java.lang.

How does Java import work?

In dynamic languages, when the interpreter imports, it simply reads a file and evaluates it.

In C, external libraries are located by the linker at compile time to build the final object if the library is statically compiled, while for dynamic libraries a smaller version of the linker is called at runtime which remaps addresses and so makes code in the library available to the executable.

In Java, import is simply used by the compiler to let you name your classes by their unqualified name, let's say String instead of java.lang.String. You don't really need to import java.lang.* because the compiler does it by default. However this mechanism is just to save you some typing. Types in Java are fully qualified class names, so a String is really a java.lang.String object when the code is run. Packages are intended to prevent name clashes and allow two classes to have the same simple name, instead of relying on the old C convention of prefixing types like this. java_lang_String. This is called namespacing.

BTW, in Java there's the static import construct, which allows to further save typing if you use lots of constants from a certain class. In a compilation unit (a .java file) which declares

import static java.lang.Math.*;

you can use the constant PI in your code, instead of referencing it through Math.PI, and the method cos() instead of Math.cos(). So for example you can write

double r = cos(PI * theta);

Once you understand that classes are always referenced by their fully qualified name in the final bytecode, you must understand how the class code is actually loaded. This happens the first time an object of that class is created, or the first time a static member of the class is accessed. At this time, the ClassLoader tries to locate the class and instantiate it. If it can't find the class a NoClassDefFoundError is thrown (or a a ClassNotFoundException if the class is searched programmatically). To locate the class, the ClassLoader usually checks the paths listed in the $CLASSPATH environment variable.

To solve your problem, it seems you need an applet element like this

<applet
  codebase = "http://san.redenetimoveis.com"
  archive="test.jar, core.jar"
  code="com.colorfulwolf.webcamapplet.WebcamApplet"      
  width="550" height="550" >

BTW, you don't need to import the archives in the standard JRE.

In JAVA, how do I determine where an import is coming from?

The point is: the exact location of a class is determined by your class path setup.

You define at some point which classes are available when compiling your application respectively which classes to ship with it.

So, when you are not using an ide - you have to search the "elements" in the class path that gets applied for your build. For example by looking into each jar file.

Given your comments: I think you have to step back. You seem to lack basic knowledge of Java. You have to understand how that WAR file is built. There should be some sort of build description; containing the dependencies and other contents of the WAR delivery. You have to analyse those. Beyond that: if these packages are from your team/company/... a simple file search might do the job. If those packages are "external", like open source libraries - then you might try to simple google for the class name; or turn to grepcode.com.

And the other thing you asked: a compiled class contains only fully qualified class names. There are no import statements in class files any more. So when a class "needs" another class, it asks the JVM to load that class (given the fully qualified name). And the JVM simply looks into the classpath, and loads the first class that matches the given name.

Import package.* vs import package.SpecificType

There is not a performance or overhead cost to doing import .* vs importing specific types. However, I consider it to be a best practice to never use import .* My primary reason for this is I just like to keep things straightward, clean and with as little ambiguity as possible, and I think with a .* import you lose that.

Why don't we import java.lang package?

Because:

Code in a compilation unit ... automatically imports all of the public types declared in the predefined package java.lang.

Source: Java Language Specification #7

Where do we import the stuff from?

The class files are physically stored on your computer. For example, go look in %JRE directory%/lib/rt.jar. Look in the archive file and you will see java packages (you can find java.util.ArrayList.class for example).

You can certainly import java.* but you will still need to qualify the paths for every package that comes after java.*

Why don't I have to import some classes?

The obvious answer is because String is used far more often than HashMap.

No. String belongs to java.lang package, which is automatically imported by the compiler.

From java.lang javadoc:

Provides classes that are fundamental to the design of the Java programming language. The most important classes are Object, which is the root of the class hierarchy, and Class, instances of which represent classes at run time.

And from Java Language Specification. Chapter 7. Packages

A package consists of a number of compilation units (§7.3). A compilation unit automatically has access to all types declared in its package and also automatically imports all of the public types declared in the predefined package java.lang.

---

Related Topics