import : Java Glossary


import
Because of the rigid source code naming convention, the Java compiler can easily find the corresponding source or class files just from the fully qualified name of a package and class. By fully qualified name I mean specifying the full package and class e.g.
java.util.ArrayList x = new java.util.ArrayList ( 149 );
The alternative to this long-winded style of coding, is to use import statements. A typical set of import statements
import java.io.*;
import java.util.ArrayList;
import java.util.Date;
import java.util.Properties;
They must come right after the package statement, before the class statement. They are traditionally kept sorted in alphabetical order. Then you can code in an
ArrayList x = new java.util.ArrayList( 149 );

Unlike C or C++ we do not need to include headers to help the compiler determine what sorts of parameters other routines want; it can go look for itself in the source or class files. The import statement is not like the C++ include. So long as you fully qualify your reference in the code to class names with com.mindprod.mypackage.myClass there is no need for imports. They just allow shorthand. Even when you do have an import, you can still fully qualify your references to classes.

You import packages/classes not files.
import com.mindprod.common17. Build;
not
import J:\com\mindprod\common17\Build.java ;
Let us say your package is called com.mindprod.mypackage and your class is called MyClass. There are two forms of the import statement:
  1. import com.mindprod.mypackage.MyClass;
  2. import com.mindprod.mypackage.*;
Then you can refer to the class as plain MyClass, static methods as MyClass.myStaticMethod() and static variables and constants as MyClass.myStaticValue, without the com.mindprod.mypackage qualification. There is no form of the import that lets you get away with coding your references without MyClass, e. g. just myStaticMethod() or myStaticValue. The most common problems with import are: For a discussion of the philosophy when to use imports and when to use qualification see the import tidier student project.

It is a great help to understanding someone else’s code, (or even your own), if you refrain from using the .* style of import with the imports giving you an explicit list of the classes you use in that class. The list of explicit imports gives you a rough idea of what the class could do and what it is likely up to. Don’t leave unused imports lying around. Use an import tidier, or Eclipse, to get rid of them, and sort the valid ones into alphabetical order. During development, it is fine to use the lazy .* form, (doing so will save you a ton of compiler errors), but once your work gels, convert over. Bon’t camouflage your use of classes by fully qualifying them and not reporting them in the import. The only time you need qualification is when there is a name clash, e.g. java.awt.List and java.util.List.

The other problem with using wildcards is this. Let’s say you use import java.awt.* to get your Label class. Then later somebody using your code has a com.wombat.superawt. Label class on their classpath. The code won’t compile, or worse, it will use the wombat Label class in place of the awt Label class without telling anyone.

Missing import Mystery

I was puzzled discovering progams without imports for classes used that still worked. You don’t need an import a class unless you use the methods of a class or mention the class name explicitly. If you just pass the result of some method directly as a parameter to another method, without mentioning the class name of the object explicitly, you don’t need an import.

This page is posted
on the web at:

http://mindprod.com/jgloss/import.html

Optional Replicator mirror
of mindprod.com
on local hard disk J:

J:\mindprod\jgloss\import.html
logo
Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.
Blog
IP:[65.110.21.43]
Your face IP:[54.91.135.161]
You are visitor number