Printable View
Hypothetically speaking, couldn't you import all the java classes by using a statement that looks like this:
I know that you'd never do that because that's too much unecessary space taken up but I was wondering if you could do that. Also if that could work, wouldn't you need a seperate statement for javax classes?Code:import java.*;
No, it doesn't work like that. It will compile, but it doesn't import packages like awt and the like. I'm really not sure what it does, but my guess would be that it imports the implicit packages such as lang or something.
That's right
for example, if you import java.awt.*; that doesn't mean java.awt.event. classes are imported
Using a wildcard when importing classes will import only the classes you have used in your code. For example if i do import java.util.*; and then an ArrayList, only the ArrayList class will be imported.Quote:
Originally Posted by ComputerJy
So even if you use a wildcard on this:
import javax.swing.*;
And you only use the JOptionPane class in your code, it ignores everything else in the swing class except the JOptionPane class?
I think it imports all classes that are defined w/n javax.swing package.. all classes in sub packages like the javax.swing.table (if im not mistaken) will not be imported.
therefore importing javax.swing.*; imports JOptionPane together with like JFrame, JApplet, etc. , except those contained in sub packages like Border for instance. (well if im not mistaken :D its been a long time). :)
Yes, it only includes classes in that level of the directory.
e.g. import A.* will import A.B, but not A.C.D or A.C.E as this are one level deeper.
However, it'd be intersting if you could so things such as:
import *; // one level deep
import *.*; // two levels deep
import *.*.*; // three levels depp
etc..
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:
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.Code:import java.awt.*;
...
button.addActionListener(new event.ActionListener() { ... });
This is in contrast to C++'s or C#'s namespace system, where the namespace have true nesting.