Redundant Imports – Building Blocks – 1Z0-829 Study Guide

Redundant Imports

Wait a minute! We’ve been referring to System without an import every time we printed text, and Java found it just fine. There’s one special package in the Java world called java.lang. This package is special in that it is automatically imported. You can type this package in an import statement, but you don’t have to. In the following code, how many of the imports do you think are redundant?

import java.lang.System;

import java.lang.*;

import java.util.Random;

import java.util.*;

public class NumberPicker {

public static void main(String[] args) {

Random r = new Random();

System.out.println(r.nextInt(10));

}

}

The answer is that three of the imports are redundant. Lines 1 and 2 are redundant because everything in java.lang is automatically imported. Line 4 is also redundant in this example because Random is already imported from java.util.Random. If line 3 wasn’t present, java.util.* wouldn’t be redundant, though, since it would cover importing Random.

Another case of redundancy involves importing a class that is in the same package as the class importing it. Java automatically looks in the current package for other classes.

Let’s take a look at one more example to make sure you understand the edge cases for

imports. For this example, Files and Paths are both in the package java.nio.file. The exam may use packages you may never have seen before. The question will let you know which package the class is in if you need to know that in order to answer the question.

Which import statements do you think would work to get this code to compile?

public class InputImports {

public void read(Files files) {

Paths.get(“name”);

}

There are two possible answers. The shorter one is to use a wildcard to import both at the same time.

import java.nio.file.*;

The other answer is to import both classes explicitly.

import java.nio.file.Files;

import java.nio.file.Paths;

Now let’s consider some imports that don’t work.

import java.nio.*;	// NO		GOOD	-a	wildcard only matches
	// class names, not “file.Files”
import java.nio..;	//	NO	GOOD	-you can only have one wildcard
	//	and it must			be at the end

import java.nio.file.Paths.*; // NO GOOD -you cannot import methods // only class names

Naming Conflicts

One of the reasons for using packages is so that class names don’t have to be unique across all of Java. This means you’ll sometimes want to import a class that can be found in mul-tiple places. A common example of this is the Date class. Java provides implementations of java.util.Date and java.sql.Date. What import statement can we use if we want the java.util.Date version?

public class Conflicts {

Date date;

// some more code

}

The answer should be easy by now. You can write either import java.util.*; or import java.util.Date;. The tricky cases come about when other imports are present.

import java.util.*;

import java.sql.*; // causes Date declaration to not compile

When the class name is found in multiple packages, Java gives you a compiler error. In our example, the solution is easy—remove the import java.sql.* that we don’t need. But what do we do if we need a whole pile of other classes in the java.sql package?

import java.util.Date;

import java.sql.*;

Ah, now it works! If you explicitly import a class name, it takes precedence over any wildcards present. Java thinks, “The programmer really wants me to assume use of the java.util.Date class.”

One more example. What does Java do with “ties” for precedence?

import java.util.Date;

import java.sql.Date;

Java is smart enough to detect that this code is no good. As a programmer, you’ve claimed to explicitly want the default to be both the java.util.Date and java.sql.Date imple-mentations. Because there can’t be two defaults, the compiler tells you the imports are ambiguous.

If You Really Need to Use Two Classes with the Same Name

Sometimes you really do want to use Date from two different packages. When this hap-pens, you can pick one to use in the import statement and use the other’s fully qualified class name. Or you can drop both import statements and always use the fully qualified

class name.

public class Conflicts {

java.util.Date date;

java.sql.Date sqlDate;

}