Hypothetical Java Question

[CornedBee]

Erm, a bit of a misunderstanding regarding the concept of a package here.

So let's see.

A package defines a namespace for classes. A class has a local name, but also a fully qualified class name (FQCN), which consists of the full package name its part of, plus its own local name.

At any time you can use the FQCN to refer to any class. Without any imports at all, I can do this:
javax.swing.JButton button;

The compiler will look up the class definition of javax.swing.JButton. It will reference that class so that it will be loaded when needed.

Perhaps I should put it this way: the import statement has no effect whatsoever on the .class files resulting from a .java file. You can import every single package in the world, and it will have no effect at all. It won't even slow down compilation very much.

The import statement does only one thing: it gives the compiler another place to look for when trying to resolve unqualified names. The default search path consists of the current package and the package java.lang. A specific import, such as
import javax.swing.JButton;
will tell the compiler to try the javax.swing package when looking for a class called JButton. A wildcard import, such as
import javax.swing.*;
will tell the compiler to try the javax.swing package whenever its trying to resolve an unqualified name. As such the line
JButton button;
will cause the compiler to first look in the current package, which hopefully doesn't contain a JButton, then in java.lang which doesn't either, and then in javax.swing, which does. The compiler will, I think, go on looking and complain about ambiguity if it finds another class, which is why specific imports are better than wildcards.

The statement
import java.*;
will cause the compiler to look up unqualified names in the package java. This package doesn't contain any classes, though - in fact, the package doesn't exist.
This is another important point about packages: their names, although they suggest a hierarchic relationship, and although they are conceptually used that way, and although they correspond to a directory hierarchy, are actually completely arbitrary. What that means is that to programmers, javax.swing.event is clearly a subpackage to javax.swing. To the language, however, these two packages are not related in any way. They have different names, and that one name is a substring of the other is of no consequence. That's why
import java.*;
doesn't retrieve anything from java.util or java.awt. These two packages have nothing to do with the package java.
That's also why sql_lall's idea doesn't work. The * isn't a shell-like wildcard, not really. It doesn't stand for an arbitrary name. It can only be placed after a package, because it means "try this package for anything", not "try to form a valid FQDN using this string pattern".
If it did the latter, then this would work:

import java.awt.*;

...
button.addActionListener(new event.ActionListener() { ... });

What happens is that the compiler first looks for a package event, assuming the name is fully qualified. It probably won't find one, so it then assumes that event is the name of a class of which ActionListener is a member, it thus tries to look up the class event. If a generic attempt to form a valid name was made, it would then manage to form java.awt.event.ActionListener. But that's not the case.
This is in contrast to C++'s or C#'s namespace system, where the namespace have true nesting.