As you saw in the previous example, Java classes are grouped into packages. The import statement tells the compiler which package to look in to find a class. This is similar to how mailing a letter works. Imagine you are mailing a letter to 123 Main Street, Apartment 9. The mail carrier first brings the letter to 123 Main Street. Then the carrier looks for the mailbox for apartment number 9. The address is like the package name in Java.
The apartment number is like the class name in Java. Just as the mail carrier only looks at apartment numbers in the building, Java only looks for class names in the package.
Package names are hierarchical like the mail as well. The postal service starts with the top level, looking at your country first. You start reading a package name at the beginning too. For example, if it begins with java, this means it came with the JDK. If it starts with something else, it likely shows where it came from using the website name in reverse. For example, com.wiley.javabook tells us the code is associated with the wiley.com web-site or organization. After the website name, you can add whatever you want. For example, com.wiley.java.my.name also came from wiley.com. Java calls more detailed packages child packages. The package com.wiley.javabook is a child package of com.wiley. You can tell because it’s longer and thus more specific.
You’ll see package names on the exam that don’t follow this convention. Don’t be sur-prised to see package names like a.b.c. The rule for package names is that they are mostly letters or numbers separated by periods (.). Technically, you’re allowed a couple of other characters between the periods (.). You can even use package names of websites you don’t own if you want to, such as com.wiley, although people reading your code might be con-fused! The rules are the same as for variable names, which you see later in this chapter. The exam may try to trick you with invalid variable names. Luckily, it doesn’t try to trick you by giving invalid package names.
In the following sections, we look at imports with wildcards, naming conflicts with imports, how to create a package of your own, and how the exam formats code.
Classes in the same package are often imported together. You can use a shortcut to import all the classes in a package.
import java.util.*; // imports java.util.Random among other things public class NumberPicker {
public static void main(String[] args) { Random r = new Random(); System.out.println(r.nextInt(10));
}
}
In this example, we imported java.util.Random and a pile of other classes. The * is a wildcard that matches all classes in the package. Every class in the java.util package is available to this program when Java compiles it. The import statement doesn’t bring in child packages, fields, or methods; it imports only classes directly under the package. Let’s say you wanted to use the class AtomicInteger (you learn about that one in Chapter 13, “Concurrency”) in the java.util.concurrent.atomic package. Which import or imports support this?
import java.util.*;
import java.util.concurrent.*;
import java.util.concurrent.atomic.*;
Only the last import allows the class to be recognized because child packages are not included with the first two.
You might think that including so many classes slows down your program execution, but it doesn’t. The compiler figures out what’s actually needed. Which approach you choose is personal preference—or team preference, if you are working with others on a team. Listing the classes used makes the code easier to read, especially for new programmers. Using the wildcard can shorten the import list. You’ll see both approaches on the exam.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
