If I do this

import android.graphics.Bitmap;
import android.graphics.BitmapFactory;
import android.graphics.Canvas;
import android.graphics.Paint;

Then why don't I do this, it's more convenient

import android.graphics.*;

Do you agree that the latter is a risk that I might import classes which conflict which my own (for example "Point" if I had one) and therefore I should not use wildcards in imports. Do you agree?

  • 3
    I think you should use an IDE that automatically adds imports. – user253751 Jul 26 '18 at 3:10
  • @immibis I do. Then it won't become wildcards. – Niklas R. Jul 26 '18 at 3:28
  • One argument for not doing wildcards is that you might create a lot of implicit dependencies. Now everything from graphics could be used, you don't know about it and additionally, while a bit of a stretch, a lot of dependencies can indicate your class is violating some software engineering principles. On the other hand, that also depends on how the structure of the library used, so wildcards can be more readable at the same time. It's a trade-off – Athos vk Jul 26 '18 at 8:27
  • Yes. Wildcards are a convenience for writing Java by hand. Let your IDE make your source more solid. – Thorbjørn Ravn Andersen Jul 26 '18 at 8:46
  • 2
    @NiklasRosencrantz: actually, modern IDEs usually have an "organize imports" feature which you can configure to use wildcard imports if there's more than X imports from the same package. Besides, the point is that if the IDE adds the imports, your "it's more convenient" argument becomes irrelevant. – Michael Borgwardt Jul 26 '18 at 11:14

It is not a bad idea, but it does have some consequences you should be aware of. It's a tradeoff.

Its simpler and shorter, and less programmer overhead typing crap. And its probably less likely to include stray includes that are not needed (though now modern IDEs detect/fix that for you so maybe that doesn't matter).

It CAN result in code that worked fine, when you upgrade the version of your libraries, suddenly stops compiling. But that is insanely unlikely (been doing this for 40 years and I've NEVER seen it happen).

Personally, I try to keep my includes minimal as a form of documentation. For library code (code that's highly leveraged) - its more important to really understand your dependencies. For application code, its a little less important.

No right or wrong - just go for what feels right, IMHO.

| improve this answer | |

Bad idea. You rely on a kind of smartness inappropriate at the compiler level. Import statements serve a documentation purpose: the reader gets an idea about the covered domains of the class. This is partly killed by the wildcard, you are not likely to actually use every namespace that fits the *.

Using a wildcard makes fuzzy code. The compiler should do what the code says, not figure out what the code should be.

| improve this answer | |
  • 1
    I agree. It adds work to the compiler, not during runtime, so in that regard it is not a big deal. However it is ambiguous and somewhat lazy programming, like reducing the typing of two characters by dropping off curly brackets on if statements which don't necessarily need them. – Neil Jul 26 '18 at 6:15
  • 9
    this answer is wrong because compiler doesn't pick anything - I just tested that with wildcard imports from java.sql and java.util - both packages contain class named Date. Compilation simply failed with error message: reference to Date is ambiguous... – gnat Jul 26 '18 at 7:41
  • 1
    I removed the part about ambiguity (which apparently is not a real problem) and stuck to the fundamental issue I have with the wildcard. – Martin Maat Jul 26 '18 at 11:11
  • 5
    Imports placed at the top of the file is not a documentation, they're just a noise you have to scroll through to get to your class. I would rather see a class name, method signatures and associated javaDoc to figure out that I'm looking at MyCarFactory that has a Create method that returns a Car given make and model than open a file and realize that I'm looking at a class that works with ArrayList, a few Strings and accesses file system. – tyshka Jul 26 '18 at 13:42
  • @tyshka, if you think imports are "just a noise", you've obviously never tried to use any example code that used 3rd party helper libraries that were unclear from context. It can be especially infuriating to figure out which HTTP library somebody is using when they all have mostly the same class names. – meustrus Feb 13 '19 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.