Using External Code in Your Programs: import Almost every time you write a new class file, you will want to give that class the powers provided by some existing external file that lives in another package. You can do that in one of two ways: -
Specify the fully qualified class name every time you reference the class. -
Import the class or the package containing the class, and then simply reference the class using its name. You do this using the keyword import. If you have used Microsoft .NET, you should be familiar with this concept. In C#, you might write the following:
using System; class MyClass { public static void Main() { Console.WriteLine("smeagol was here"); } }
That's how you specify that you are going to use one or more of the classes in the System namespace in C#. C# namespace ~= Java package. If you have used C#, you will find not just this section, but much of this book fairly easy going, as Microsoft has helped itself to very generous portions of Java's syntax in creating C#. You'll find that with a little tuck here and a little nip there, some of your Java code will compile directly to MSIL (Microsoft Intermediate Language used in .NET). When writing code, the choices for using external classes boil down to the following options. First, your code without import:
net.javagarage.monsters.Vampire vampire = new net.javagarage.monsters.Vampire();
Second, your code with import:
import net.javagarage.monsters.Vampire ... Vampire vampire = new Vampire();
Note that you can import all of the classes in a package using the common wildcard character * . To import all the classes and interfaces in the monsters package, write
import net.javagarage.monsters.*;
That way, your code can do this all day long ( assuming your "monsters" package has classes named Mummy and Werewolf in it):
Vampire vampire = new Vampire(); Mummy mommy = new Mummy(); Werewolf werewolf = new Werewolf();
Look, ma ”no fully qualified class names ! Keep this in mind: trying to decide whether to import all of the classes in a package using * or importing only the class from that package that you need is not a very interesting dilemma. In fact, it is no dilemma at all. They both perform the same and result in the same class file size . When you import all of the classes in a package using * , the Java compiler does not do what you ask. Instead, it determines what classes in that package your code actually references, and imports only those. So don't worry about the efficiency of code that uses the * wildcard to import. My recommendation is to use the wildcard if you are lazy, or if you need more than one class from the same package. If you have a number of less- experienced developers on your team (or you yourself are easily confused ), you might want to explicitly import each class, even when they're in the same package, to make the code more readable.  | FRIDGE Many IDEs will help you organize your imports so that you don't have to think about it too much. In Eclipse, for example, you can right-click anywhere on your source code file and choose Organize Imports ”this kind of thing will help keep your code clear and clean. | |
Automatically Imported Classes One last thing about packages. You might have noticed that you can just write, compile, and execute this code:
package com.monsters; public class Vampire { public static void main(String [] args) { String music = "punk"; System.out.println("Tony Blair's fave music is "+ music); } }
A question arises here. Why don't we have to import String? That is a Java class made available in the API, and it is in the java.lang package. You don't have to import classes in java.lang package: all of the classes in that package are always automatically imported for you. That means that you could write this to get the same result as in the preceding :
java.lang.String music = "punk";
Static Imports Static imports are new with Java 5.0. In previous examples, we have used the class name as a prefix to calling the static methods of the Math class, such as Math.random() . This is okay, but it is also unnecessarily verbose. To facilitate ease of use in other classes with the static methods and static variables , you can add the static keyword to the import directive and import them all so that you don't have to use the class name as a prefix to calling them anymore. So, you have a choice between writing this (which is how we used to have to do it)
public class MathClient { public void x() { double d = Math.random(); //...blah blah } }
and writing this:
import static java.lang.Math.*; public class MathClient { public void x() { double d = random(); //look! no "Math."! //...blah blah } }
Using static imports is meant to help clear up code that becomes overburdened by numerous , repeated calls to constants that clutter up your code. StaticTestConflict.java
package net.javagarage.statimp; import static net.statimp.MyConstants.*; import static net.statimp.MyOtherConstants.*; public class StaticTestConflict { public static void main(String[] args){ System.out.println(SOME_PROPERTY); } } class MyConstants { static String SOME_PROPERTY = "MyConstants value"; } class MyOtherConstants { static String SOME_PROPERTY = "MyOtherConstants value"; }
Note that it is okay to declare multiple classes in the same source file as long as only one of them is declared public. But you can't compile this code if you do not fully qualify the reference to the property with the class name as we have done. Here's what the compiler says about it.
reference to SOME_PROPERTY is ambiguous both variable SOME_PROPERTY in net.statimp.MyConstants and variable SOME_PROPERTY in net.statimp.MyOtherConstants match System.out.println(SOME_PROPERTY); 1 error
You might think that you would not be able to use static imports to import two separate methods with the same name in different packages. For example, the Integer compareTo() method and the Byte compareTo() method both have the same names. However, they have different signatures: the compareTo() method from Integer accepts an Integer, and the method with the same name in Byte accepts a byte. Because of this, your namespaces stay separate, and the following lines of code are legal:
import static Integer.compareTo(); import static Byte.compareTo();
The runtime will be able to sort them out. So. Yeah. That's all I want to say about imports right now. I hope that that answers all of your questions about this stuff. If, after this, you have more questions about packages and imports, you might consider getting a Zoloft script; as my cousin August says, "Better living through chemistry " Otherwise, try taking up a hobby, like gardening , or hot rod racing. | 