Is there any advantage/disadvantage to these two types of Import statements: import javax.swing.*; and import javax.swing.JButton; If I am only using a JButton from the swing classes and nothing else. I realize that won't happen, but I think you get the gist of what I am asking. Should we import all classes or just classes we use? ------------------ Happy Coding, Gregg Bolinger
Since using one form over the other has no effect on performance, I think it all boils down to style. I've seen conflicting advice on this: some say specific imports are better than package imports and some say the opposite. My personal preference (since I'm a lazy programmer ) is to just do the package import. A good compromise I've seen is if you use one or two classes from a package, use specific; more than two, use package. Junilu
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
Cool, thanks. Another question to add on top of this. Why is it that when you: import java.awt.*; it doesn't import the event classes? I always have to have the two lines: import java.awt.*; import java.awt.event.*;
Gregg Answer to 1st question: As far as I know the import statement just lets you use the simple name of classes, like being able to simply say Vector instead of java.util.Vector Here is where I get confused... I think import also tells the compiler where to find the classes named in the import statement but the compiler doesn't actually get them all it just gets the ones it needs not all of the ones in the pakage. On the other hand it might be the jvm itself that gets class files it needs at run time (I'm honestly not sure, going to have to read up on that). either way using the wildcard '*' doesn't add anymore size to your class file or make it any less efficient. Answer to 2nd question: that one bothered me too until I read about somewhere - can't remember where though. package statement only resemble a file system heirarchy in the fact that the path to a class will match the package statment but they are not heirarchical in the sense that a package named com.myclasses.utilities does not contain a package named com.myclasses.utilities.datestuff They are two completley separate packages so you have import both packages. Even though it looks like the one is contained in the other, they are really separate.
------------------ Dave Sun Certified Programmer for the Java� 2 Platform [This message has been edited by Dave Vick (edited December 21, 2001).]
Is there any advantage/disadvantage to these two types of Import statements: import javax.swing.*; and import javax.swing.JButton;
For the most part, I believe the difference is one of style. Personally, I always use specific imports. I've found, if you ever have to maintain your code months or years down the road (or someone else's code, for that matter), having specific imports can help you track code into various packages. This can be useful if you ever have to update a few areas of an existing application. Anyway, enough about that, here's a real situation where using package imports can get you into trouble: Namespace Pollution. The problem with using package imports (in this case), is that you end up with class names available for a lot of classes that you're not using. This can lead to ambiguity errors from your compiler. Take the following example: package java.pets contains the following classes Dog Cat Bird Fish package java.dogs contains the following classes Dog Bulldog Chihuahua CockerSpaniel Notice that each package contains a class called Dog and a bunch of other classes, as well. Now, look at the following code, in which we make use of the two classes java.pets.Cat and java.dogs.Dog:
In case you didn't catch it, this code won't compile (at least it shouldn't, I haven't tested this). The problem is that the compiler doesn't know which Dog class you mean, either java.pets.Dog or java.dogs.Dog. Both classes have been added to your namespace because of the package imports. This error is a result of namespace pollution - too many names available. There are two ways to solve the problem. 1. Use specific imports. 2. Fully qualify java.dogs.Dog in the declaration of Fido. In this case, I'd say using package imports is more trouble than its worth. Don't get me wrong, package imports are nice and, even when using specific imports, you can run into namespace problems. Imaging if you have to use both java.pets.Dog and java.dogs.Dog in your program. Even if you use specific import statements, your only choice is to fully qualify the name of the class with the package name. But, I've found this happens much less often when using specific import statements. Take it for what it's worth, but I still say it all comes down to style. Namespace issues don't crop up all that often. Corey
Some people feel very strongly that you should avoid *'s in imports. If you look at source code written by Sun or other large companies with strict standards you'll probably see explicit imports. ImportScrubber proudly declares: "no more '"import-on-demand'"
Yes Gregg you're right - good discussion. I was thinking on this for quite a long time but never find enough courage to post same. I would like to thank you Gregg to intiate this question and all other who has given their thoughts. regards, Arun
I'm passing on this link that someone shared with me. It's a discussion about this very question, to use wildcard imports or not. Until now, I've only used .* imports, but the code I write is all practice, not something someone else will have to figure out and maintain down the line. groups.google.com/groups?hl=en&threadm=3A7AE095.548DF5CD%40geocities.com&rnum=4&prev=/groups%3Fq%3Dimport%2Blist%2Bgroup:comp.lang.java.programmer%26hl%3Den%26rnum%3D4%26selm%3D3A7 AE095.548DF5CD%2540geocities.com It's a long link, but it does get you there (preceded by http:// ) Pauline [This message has been edited by Pauline McNamara (edited December 30, 2001).]
We can fix it! We just need some baling wire, some WD-40, a bit of duct tape and this tiny ad:
Sauce Labs - World's Largest Continuous Testing Cloud for Websites and Mobile Apps