Java Programming

Correct. There aren't really "subpakcages." The JLS actually uses that term, but I don't know why. There's no real hierarchy, other than the one on the filesystem and the logical one implied by the names. As far as Java is concerned, the packages have no relation to each other.
No.
If it could be done, the disadvantage would be the same as that of using the *** wildcard to import all the classes at a single level. Namely, it's not clear which class comes from which package.

The answer is no, and it's deliberate.

I can't find the rationale on line any more, but this was discussed in the early Java days.

The import statement is an aliasing mechanism. It tells you that com.foo.reallyfoo.Bar maps to Bar, so you can just use "Bar" in your program. It doesn't make a lot of sense to let the user alias everything at once, including things they'll never use, and things that conflict with each other (e.g., java.awt.List and java.util.List). If packages are (among other things) a namespacing mechanism, then a sort of universal automatic aliasing would undermine that.

I'd argue that use of the wildcard during imports is itself a bad code smell. Often it's unavoidable. But if I see too many imports or too many imports with wildcards (the threshhold is lower in the latter case) then I take it as a sign that the class might be trying to do too much.

Ahhhh, thanks, everyone. It all makes perfect sense now. I read the online documentation, which told me that it is not hierarchical, as jverd stated. So there is no way to make it work.

And paulcw, I get what you're saying about the namespacing. That really clears things up.

Thanks again!

Despite doing just that quite regularly in SSCCEs (which were never intended to be 'well designed code'), I fully agree with you.
Why? I cannot think of any situation where it is actually unavoidable.
---------------
Even in the SSCCE example mentioned above, it is not ruled out to provide explicit imports, it just makes the SSCCE to be 'not as Short as it could be'. Further, I do not recall ever seeing an SSCCE criticised specifically for having explicit imports (and I've seen a lot of them!).

Why would you really want to do this? There are multiple classes in the java api that have the same class name.

You're asking me? You replied to my post.

<DWS>Because..

import *;

..makes my code run faster.</DWS>

Edit 1:
And before anyone takes that seriously, I better add the DWS stands for Dripping With Sarcasm.

Edited by: AndrewThompson64 on Feb 27, 2010 6:21 PM

Actually the only case I can think of offhand is GUIs. In my experience, sometimes you end up where you need a bunch of GUI elements from a single package to do almost anything, and at that point you might as well just "import javax.swing.*;", IMHO. "Often" was probably the wrong term; "occasionally" would be better.

It's not unavoidable, but in some cases decomposing the class into smaller classes itself would add more complexity than just importing a lot of GUI widgets. In my experience anyway.

That won't cause problems, except for the developer reading the code, but the plain old one-level wildcard import we have now can cause the same problems. Namely, you can't always tell which package a given class came from.

Thanks for the clarification. I think we are now on the same wavelength.

YET.
There are plans (I think approved by the JCP) to enable importing of class hierarchies in JDK 7. Not my favourite idea, but others seem to think differently.
Worse than that. If you have identically named classes in deeper packages which one is going to be used? You just can't tell, which hopefully will generate a compiler error.

For example you import com.acme.dummy recursively, which has com.acme.dummy.one.SomeClass and com.acme.dummy.two.SomeClass.
Now use SomeClass in your code without specifying the package name with it and you're in trouble.

I think jverd already alluded to this already being a problem today. If you import both packages {noformat}com.acme.dummy.one.* and com.acme.dummy.two.*{noformat} you don't really know what SomeClass refers to. While this problem can be sidestepped by defining a total order, given modern IDEs it seems a pointless complication.

With kind regards
Ben

Wow, look at all these replies! This is an interesting thread.
To answer your question, I was just thinking that maybe by doing it hierarchically and recursively, you wouldn't have to worry about trying to figure out why the compiler is generating errors, only to discover that you forgot to import some class.

But after lurking on this thread for a few days and poking around, I can see that it would be both undesirable and in some cases cause a conflict.

One more question: Say you were to define your own class named Foo and put it in the same package as your main classes in your project. If a pre-defined class named Foo already exists in the Java API, your program would just use your user-defined Foo, provided you did not import the officially-defined Foo class. Correct? And you would not even have to make an import statement for your own Foo.java, because the compiler automatically adds it, correct? Just want to make sure I have that 100% straight.

That sounds about right.

With kind regards
Ben

Indeed it can be. But now at least you have to explicitly import both those packages.
If hierarchical import is implemented, it's implicitly imported giving rise to much more confusion.

I'm no big fan of wildcard imports, btw :)

I would imagine so, as that's what it does now for single-level imports (but only if you try to use the class, which is a good approach, IMHO).

import java.util.*;
import java.sql.*;

void foo() {
  Date d; // compiler error
}

If we add an explicit import of the Date class we want, the error goes away.

If you're a newbie using a simple editor, this will be an occasional minor annoyance that will help to remind you to import what you need.

If you're a professional developer using a professional grade IDE, the IDE should offer to add the import automatically. IntelliJ does, and IIRC, Eclipse does as well. I would imagine others do too.

Shift+Ctrl+O in Eclipse ftw. You never have to worry about manually typing in imports.

Ctrl-Shift-I in NetBeans.

That's the one I was looking for. Thanks! I probably never would have thought to do this.

But wait a minute. If there are classes with identical names, how would the editor know which package to import the class from? Please forgive my ignorance.

Eclipse pops up a box listing all possible classes. I assume Netbeans would do the same.

**smacks forehead**

Of course, of course. I've only used the java.awt.Colors and java.awt.Graphics classes so far. Tested out out the hotkey import feature and didn't get any options. Guess those are unique, then. Thanks again.