Meaning of the Import Statement in a Java File

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.

Java import statement syntax

Per the JLS 7.1:

The members of a package are its subpackages and all the top level class types (§7.6, §8) and top level interface types (§9) declared in all the compilation units (§7.3) of the package.

For example, in the Java SE platform API:

• The package java has subpackages awt, applet, io, lang, net, and util, but no compilation units.

• The package java.awt has a subpackage named image, as well as a number of compilation units containing declarations of class and interface types.

If the fully qualified name (§6.7) of a package is P, and Q is a subpackage of P, then P.Q is the fully qualified name of the subpackage, and furthermore denotes a package.

So you can glean from that:

• java is a package with no classes, only subpackages.
• util is a subpackage of java whose fully qualified name is java.util.
• util does not denote a package, java.util does.

"I also found this picture: ... Is it true?"

Yes, util is a subpackage of java. However, util is not a package. java.util is a package.

You can think of packages as a directory structure, if you wish, where each subpackage is a folder inside its outer package. So there would be a "folder" java and, inside that, another "folder" util. A package is denoted by its fully qualified name ("full path") so java is a package and java/util is a package. /util is not a package. But packages represented by a directory structure is not a spec. It is only a common implementation. It is up to the host system to decide how packages are stored (JLS 7.2).

What is an import called?

"declaration"

See also

• JLS 7.5. Import Declaration
  
  
  • 7.5.1 Single-Type-Import Declaration
  • 7.5.2 Type-Import-on-Demand Declaration
  • 7.5.3 Single Static Import Declaration
  • 7.5.4 Static-Import-on-Demand Declaration

Import a custom class in Java

If all of your classes are in the same package, you shouldn't need to import them.

Simply instantiate the object like so:

CustomObject myObject = new CustomObject();

why java allows importing a class defined in same file?

There are cases where it's necessary to import a class defined in the same file. Your example surely isn't one of them (your import is simply superfluous because classes in the same package are in the same namespace, which roughly means that classes in the same package are implicitly imported).

But look at this (suppose all code is in the same file):

package stackoverflow;

import stackoverflow.OtherClass.OtherClassInner;

public class Main {
    public static void main(String[] args) throws Exception {
        OtherClassInner inner = new OtherClassInner();
    }
}

class OtherClass {
    static class OtherClassInner {

    }
}

In this case, Main is not in the same namespace as OtherClassInner, so it either has to fully qualify stackoverflow.OtherClass.OtherClassInner (or reference it through OtherClass.OtherClassInner as Main and OtherClass don't need to import one another), or to import it as shown in the above snippet.

And just to make it obvious why the import is necessary, consider this (where there are two OtherClassInner in the same file):

public class Main {
    public static void main(String[] args) throws Exception {
        OtherClassInner inner = new OtherClassInner();
    }
}

class OtherClass {
    static class OtherClassInner {

    }
}

class YetAnotherClass {
    static class OtherClassInner {

    }
}

---

Related Topics