This question already has answers here:
Why is using a wild card with a Java import statement bad?
(18 answers)
Closed 7 years ago.
In some of the resources I have seen online about Java they say that it is not good to use the * in an import statement in Java. For example import java.io.*
I was wondering why this is considered bad practice. Is is solely because it makes it hard for another programmer to know exactly what classes you are using under the java.io package or is there another reason for it?
Because Java.io.* imports the entire IO class. This means the program will be loading components that it won't need.
This question already has answers here:
Java import all from all
(3 answers)
Closed 9 years ago.
Why doesn't import one.two.* include import one.two.three.MyClass?
Shouldn't Java have something like import one.two.**? Or is there any reason (other than they just didn't do, not that they couldn't do it)?
Thanks
Java does not treat packages as truly subclassing each other; while java.util and java.util.concurrency might look like the second is somehow part of the first, they are treated as entirely independent and the dot is mostly there for neatness.
This means you don't need to be afraid of naming your class or interface the same as another one declared in some super- or sub-package on a later date, and it also means you should really just write a couple extra lines of imports.
The reasons behind this decision, as Peter Lawrey explained, stem from Java's general lean towards simplicity. Best practice is often to never use import wildcards at all anyway.
Java treats each package as independent. For example, package local don't extend to any "sub" packages. I suspect using the hierarchy in a meaningful way would be valuable but Java's design was to make everything as simple as possible.
Or is there any reason (other than they just didn't do, not that they couldn't do it)?
The problem is backward compatibility which might break older programs. I suspect this is solvable.
In truth, most IDEs manage your imports for you and I don't even look at my imports any more. Certainly avoiding import * is preferable so that all classes are explicitly imported.
This question already has answers here:
Why is using a wild card with a Java import statement bad?
(18 answers)
Closed 10 years ago.
Can someone explain me the import statements in Java. Some import has * suffixed to it and some doesn't. What is the difference between these two? Does the use of * in the import statement imports all the classes?
see here import
Here they have said that though the import statements seems nested they are not so.
Can someone explain in detail?
The use of * is considered a bad practice. It is used to import all files within that package. The more correct way of doing this is listing off each of the classes that you need, specifically in a scenario where you are doing a code review outside of an IDE and need to know which version of the class you are using. Essentially it breeds laziness in the development team.
Comment
For those arguing that this is not a "bad" practice as I have stated. How can you possibly say that this is a good practice?
import java.util.*;
import java.io.*;
Even if the compiler ignores everything under the * except the List that you have imported, how does this possibly help someone looking at the code in the future? I think a good deal of people here forget that you are writing code for humans and not the computer. Further how could you possibly convert this code when Java goes away and you are using SuperAwesomeLanguage? Given the following example please convert this to your new language when you have ZERO knowledge of java:
public class Foo
{
private List list;
}
Is List in io? is io even required? The issue is you don't know. So by being explicit you can guide future developers as to what classes are required.
Does the use of * in the import statement imports all the classes
Yes.
From Oracle's Documentation :
A type-import-on-demand declaration allows all accessible types of a
named package or type to be imported as needed.
From your link:
import java.util.*;
The * is a "regular expression operator" that will match any
combination of characters. Therefore, this import statement will
import everything in java.util. If you have tried entering and running
the example program above, you can change the import statement to this
one.
So yes * suffix imports all classes in this path
import com.example.*
Imports all classes in the com.example package
import com.example.ClassName
Imports just the ClassName class
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Import package.* vs import package.SpecificType
while importing packages in java does it matter if I import all classes or is it better to use specific imports.
For example is it better to use import java.util.*
or to import the specific class of the util package which my program uses.
It makes no difference at all at execution time. The compiled code will be identical - and it will also be identical to the equivalent code with no imports, but every type name specified in full at every point in the code.
It will almost certainly make no significant difference at compile time either.
Personally I use a wildcard import when writing throwaway code by hand (e.g. for samples on Stack Overflow) but get Eclipse to import specific classes when writing real code.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 days ago.
Improve this question
Is it better to list each individual piece of a package you're going to need (see #1) or is it better to just import everything from a package (see #2)?
1
import java.awt.image.ColorModel;
import java.awt.image.ComponentColorModel;
import java.awt.image.ColorConvertOp;
2
import java.awt.*;
It's NOT simply a matter of style; import-on-demand can result in code that ceases to compile as new classes are added to existing packages.
Basic idea
(See http://javadude.com/articles/importondemandisevil.html for details.):
import java.awt.*;
import java.util.*;
...
List list;
worked in Java 1.1; as of Java 1.2, the above code will no longer compile.
Import on demand is EVIL because your program can stop compiling when new classes are added to existing packages!
ALWAYS use explicit imports. It's not a matter of style; it's a matter of safety.
This is especially bad if you check in perfectly-compiling code and a year later someone checks it out and tries to compile it with new class libraries.
(Import-on-demand is an example of a really bad programming language feature - no feature should break code when new types are added to a system!)
Use import individually.
It is way lot better for production code to list each and every one of the classes being imported.
While the IDE's do a great job helping you know which classes are being used, it is more readable to know that you're referring to :
java.util.List;
and not
java.awt.List;
and so on.
Additionally it is recommended that you group them by package starting by the core libraries passing by 3rd party and ending with own project libraries:
import java.util.List;
import java.util.ArrayList;
import java.util.Date;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.event.TableModelListener;
import org.apache.commons.httpclient.cookie.CookiePolicy;
import org.apache.commons.httpclient.cookie.CookieSpec;
import your.own.packagename.here.SomeClass;
import your.own.packagename.here.OtherClass;
Using wildcard is acceptable for small self project/classes. It is faster, but it is not expected to be maintainable. If any other developer is involved, use the first.
The latter is generally considered "bad form". With tool support, there's no excuse for not listing them individually, and it removes any ambiguity.
Mind you, Eclipse by default uses wildcards for static imports, and explicit imports for normal ones. Not sure why it makes that distinction.
edit: the distinction is obvious in hindsight - static imports often refer to static methods, and you can't unambiguously refer to a static method by name (due to overloading). So if it can't be fully unambiguous, you may as well use a wildcard.
I know the question was not about performance but, the cost of import statements question of the month on javaperformancetuning.com perfectly summarize why you should avoid to use wildcards:
(...)
Finally, many people find that using
imports with wildcards makes the
source much less readable, since the
reader also needs to figure out which
package a particular class comes from,
rather than just looking it up in the
import statement.
So the full answer is
There is no runtime cost from using an import statement
The compilation process can take a little more time with an import
statement
The compilation process can take even more time with a wildcard import
statement
For improved readability, wildcard import statements are bad practice for
anything but throwaway classes
The compilation overhead of non-wildcard import statements are
minor, but they give readability
benefits so best practice is to use
them
It is a bad practice to use wilcard import statements, they make the code less readable, just don't do it. The only exception to this rule are static import, for example import static org.junit.Assert.*;. No, I don't want to import each assertXXX individually and I don't find that this harms code readability.
If you list them individually it is easier to detect, when reading code with a simple editor (rather than from inside a dev environment), which package objects come from. When reading code from complex projects this can save significant time. Had an example of that earlier today, in fact, when I was studying code from a large open source project without wanting to load everything into eclipse.
If you use an ide like visual studio it typically takes care of this issue for you, so you don't even need to bother thinking about it.
Most IDEs that I am aware of choose option 1 above. This is consistent with some code analysis tools that I used in the past (like checkstyle), as they consider it bad practice to use the * notation.
The option 1 you listed is preferable but if there are more classes you are importing from say java.awt.image, then its preferable to just have one import java.awt.image.* Most IDE's let you specify the exact count of the number of imports to be used. For eg in IDEA, we can use File->Settings->Code Style->imports In the General tab there is a field Class count to use import with * and default value is 5.
whatever the default of your team's IDE is. that way you can just do an autoformat of your file before committing it.
There is no one right answer here.
The People Who Brought You Eclipse voted for individual imports, since Source/Organize Imports will convert the * form to the specific form.
Import individually, it saves the compiler from having to look through each package for each class and therefore makes things run quicker.