为什么要定义多个导入？

Question

Consider the following import statements:

import java.io.*; // Make sense

import javax.servlet.*;

import javax.servlet.http.*;

Isn't it like that we have included "import javax.servlet. ;" and therefore it will automatically include the other import statement as well which is "import javax.servlet.http. ; " ?

Why "import javax.servlet.http.*" is explicitly defined for http ?

Please clarify and let me know if I'm wrong.

Answer 1

No when you import something you import only either a specific class or you import the package and with that all the Classes that belong to that package but not the classes that belong to sub-package of that package.

Each package contains somewhat related Classes and sub-packages. Classes in sub-package are not necessarily related to classes in parent package. So it would make no sense to import those as well. This way you avoid needless imports and keep your project clean.

Example:
Let's say you are building a View class for your GUI application you may want to separate concerns so you would have JComponents in your View and your Listeners in your Controllers.

So in your View you would import: import javax.swing.*; this way you would get all the JComponent classes but since you don't need event package in your View it makes sense that import only imports what you actually need. Even tho swing and event package are somewhat related there is no need to import event as well.

So when you are importing something in Java you are either importing entire package import javax.swing.*; With all the classes that concern the package or you are importing a single class of the package import javax.swing.JButton;

You never import package with all of it's sub-packages and their sub-packages etc. As it's highly likely that you do not need all of them.

Answer 2

Yes, you DO need to do a wildcard import for each package.

Why? As far as the JLS is concerned "com.example" and "com.example.pkg" are unrelated packages. The notion of a subpackage is mentioned in the JLS, but there is no associated semantic. In particular not in the "access" rules. JLS 7.1 says:

"The hierarchical naming structure for packages is intended to be convenient for organizing related packages in a conventional manner, but has no significance in itself other than the prohibition against a package having a subpackage with the same simple name as a top level type (§7.6) declared in that package.

For example, there is no special access relationship between a package named oliver and another package named oliver.twist , or between packages named evelyn.wood and evelyn.waugh . That is, the code in a package named oliver.twist has no better access to the types declared within package oliver than code in any other package."

(And a construct that allows import of a number of unrelated packages has bad consequences ... see below.)

But Why? Because that is the way that the language is designed.

But WHY? You would need to ask the Java language design team what their thinking was in the early 1990s when the design decisions were being made.

---

But maybe we can see what would happen if there WAS a multi-package wildcard import.

Consider this package structure, which is a pretty common pattern:

  com.example.weazellib - contains the public API classes for the library
  com.example.weazellib.impl - contains implementation classes that 
                               shouldn't be used by external clients

It is a well known fact that programmers are lazy (OK a lot are), so some programmer is likely to write this:

  import com.example.weazellib.**    // hypothetical syntax

He / she will now have both the external API classes and the internal classes in this classes namespace, and it will be easy to accidentally create a dependency on the internals.

(And before you say "make the internal classes package private" ... that doesn't work. There are classes in com.example.weazellib that need to be able use classes in com.example.weazellib.impl . If the latter were package private, then the former would not be able to use them.)

By contrast, in the world where Java doesn't have wildcards that import package "trees", you can't do that accidentally . You have to deliberately import the impl package. This is A GOOD THING , and much more important than the "inconvenience" of writing wildcard imports for multiple packages.

---

The other problem is that wildcard imports are not good for long term source code stability, and super-wildcards would make it worse.

Suppose that a programmer decided that importing both com.example.weazellib and com.example.weazellib.impl was the right thing to do in his code ... and uses a super-wildcard to import both. And suppose that he writes his code to use com.example.weazellib.impl.ToesImpl ... as ToesImpl .

Now consider what happens if the "weazellib" developer adds a third package com.example.weazellib.impl2 that contains alternative implementation classes ... with the same simple names as the classes in impl ; eg we now have classes like:

com.example.weazellib.impl.ToesImpl
com.example.weazellib.impl2.ToesImpl

What happens? Well now the programmers code has a compilation error in it. ToesImpl is ambiguous ... because of the effects of the super-wildcard import pulling in class names from a package that wasn't there before.

Note that the same problem exists with regular wildcard imports. That's why a lot of people don't use wildcard imports. But there is no doubt that super-wildcards would make the problem a lot worse.

Answer 3

It is defined in the spec how import works.

See Java Language Spec

The reason is javax.servlet and javax.servlet.http are different packages, and import * only brings in the package members.

Also, its not a good idea to wild card import as it makes the code less readable.