• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

What is the disadvantage of using "*" in an import statement??

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is the disadvantage of using "*" in an import statements? Any perfect reply please!!!

 
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"*" includes all import under that package.
So if you use only one class and for that you use * in import, it will import all the classes under that package most of which may not be even referred in your code.

Also, its a bad coding practice.

Thanks and Regards,
-------------------------------------------------------------------------------------
Komal Renu | krenu@infocepts.com | www.infocepts.com
-------------------------------------------------------------------------------------
 
raj londonboy
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Komal for the reply. With that said, it also doesn't make any sense to have 60-70 import statements in java file (Coding standard).

I was wondering if importing files using "*" make any difference on compile time when we have to build lot many projects on CI servers??

 
Ranch Hand
Posts: 54
Eclipse IDE Spring Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's not clear what classes you are importing so you might end up using a class that is not form the package you expect. Say you want to use com.exmaple.myapp.alpha.Point but com.exmaple.myapp.beta (which you imported with a *) also had a Point class. IDEs tend to take care of the imports for you anyway. Eclipse for example will manage the imports and hide them so you don't end up with a visible long list unless you want to.
 
Komal Renu
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is no affect on runtime performance.

The import directive is a compiler directive. The Java source to bytecode compiler reads the Java source file (i.e. a something.java file) and converts that source to one or more bytecode files (.class files).

Most Java source code in the Java source file is converted into Java bytecodes of one sort or another. But the import directive is not. The import directive specifically tells the compiler to do something. The import directive tells the compiler that when it comes across a class or interface name in the source file, e.g. HashMap, then if it cannot find the class file for that name, it should use the import statement to help it look it up. This way, you don't have to always use fully qualified class names, e.g. java.util.HashMap.

The import directives themselves do not get put into the compiled bytecode files. They are no longer of any use, as the compiler compiles the fully qualified name into the .class file.

For example, suppose the source file contains

import java.util.*;
//
...
HashMap map;
...

Then the compiler gets to the HashMap map variable declaration, tries to find a class called HashMap in the default package (i.e. no package name), fails, and uses the import statement to see if there is a java.util.HashMap class. This is found, and a reference to java.util.HashMap is inserted into the .class file. After compilation is completed, there is no use for the import directive, so it is not present at all in the compiled bytecode. Consequently, the import directive cannot affect runtime code execution in any way.

However, it is worth noting that the directive does affect compilation time. Since the directive tells the compiler how to do a second lookup to find classes, obviously this means that more time is spent looking up class and interface names compared to if one lookup sufficed.

There are two forms of the import directive: with and without the wildcard '*', e.g.

import java.util.*;
import java.util.HashMap;

Without the wildcard, the directive tells the compiler to look for one specific file in the classpath. With the wildcard, the directive is telling the compiler to look for the named package, and to search in that package for possible matches everytime any name needs to be matched. This latter version is probably going to be more costly (i.e. take longer) for the compiler than the former.

Also, depending on which compiler you use, and which settings, the compiler may re-compile all of the classes in the wildcard package, which could really make things take longer.

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

Also, in a scenario where your class ends up having 60-70 imports, its a good practice to break up the class into two (or more) on the basis of functionality. In an Enterprise level application the classes are generally focused on the functional segregation rather than all code in one or two classes.

Thanks and Regards,
-------------------------------------------------------------------------------------
Komal Renu | krenu@infocepts.com | www.infocepts.com
-------------------------------------------------------------------------------------
 
Ranch Hand
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Komal Renu wrote:"*" includes all import under that package.
So if you use only one class and for that you use * in import, it will import all the classes under that package most of which may not be even referred in your code.


No. compiler is smart enough to import a particular referenced class from the package![compile time may *bit* high ]
actually if you use decompiler, then you can understand the behind the scene. so class file dont contain the wilcard import statement.
but importantly if you use wilcard import statement, you loose clarity[expressiveness]!
for example:
 
Seetharaman Venkatasamy
Ranch Hand
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
and Welcome to JavaRanch raj
 
Komal Renu
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Seetharaman,

If we use wildcard, the compiler looks for named package and then search the package for every possible match.

I totally agree with you on the fact that the code loses expressiveness

Thanks and Regards,
-------------------------------------------------------------------------------------
Komal Renu | krenu@infocepts.com | www.infocepts.com
-------------------------------------------------------------------------------------
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Seetharaman Venkatasamy wrote:

Komal Renu wrote:"*" includes all import under that package.
So if you use only one class and for that you use * in import, it will import all the classes under that package most of which may not be even referred in your code.


No. compiler is smart enough to import a particular referenced class from the package![compile time may *bit* high ]
actually if you use decompiler, then you can understand the behind the scene. so class file dont contain the wilcard import statement.


Actually, Komal is right: if you use "import ... *", then you are importing all classes from that package. The way a class is imported in a source file has no bearing on what ends up in the class file (which is what the compiler is smart enough to do).

Note that using "import ... *" isn't necessarily the same as importing all classes in a package individually - in the presence of multiple classes having the same name (but being in different packages) it makes a difference.
 
raj londonboy
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks eveyone for their valuable input. I read very interesting excerpt from the book "clean code" by Martin C which mentions something like:

From Clean Code, p307:


" J1: Avoid Long Import Lists by Using Wildcards
If you use two or more classes from a package, then import the whole package with
import package.*;

Long lists of imports are daunting to the reader. We don’t want to clutter up the tops of our
modules with 80 lines of imports. Rather we want the imports to be a concise statement
about which packages we collaborate with.

Specific imports are hard dependencies, whereas wildcard imports are not. If you specifically
import a class, then that class must exist. But if you import a package with a wildcard,
no particular classes need to exist. The import statement simply adds the package to
the search path when hunting for names. So no true dependency is created by such
imports, and they therefore serve to keep our modules less coupled.

There are times when the long list of specific imports can be useful. For example, if
you are dealing with legacy code and you want to find out what classes you need to build
mocks and stubs for, you can walk down the list of specific imports to find out the true
qualified names of all those classes and then put the appropriate stubs in place. However,
this use for specific imports is very rare. Furthermore, most modern IDEs will allow you
to convert the wildcarded imports to a list of specific imports with a single command. So
even in the legacy case it’s better to import wildcards.

Wildcard imports can sometimes cause name conflicts and ambiguities. Two classes
with the same name, but in different packages, will need to be specifically imported, or at
least specifically qualified when used. This can be a nuisance but is rare enough that using
wildcard imports is still generally better than specific imports."


What is your recommendation after reading this??
 
Ranch Hand
Posts: 206
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you use more than 10 classes in the same package I'd use the Wildcard, otherwise, use specific class name as much as possible for clarity and readable codes.

The choice is yours...
 
raj londonboy
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tommy Delson wrote:If you use more than 10 classes in the same package I'd use the Wildcard, otherwise, use specific class name as much as possible for clarity and readable codes.

The choice is yours...




So, you mean if you are using java.util package which is having more than 10 classes, you prefer using java.util.* in java files.

 
Tommy Delson
Ranch Hand
Posts: 206
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No, I meant if you use more than 10 classes in that package then use the Wildcard for that package, otherwise, use specific name.

If you just use a Date or other classes in java.util package that's less than 10 or 5 is your preference then use specific name.

For example,



Hope that clear your confusion...
 
Ranch Hand
Posts: 300
Eclipse IDE Firefox Browser Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

not only * but also keeping any unused imports is not a good practice, most of IDE give you warning on that , its just make sense to keep only what you use. Also argument given against it that it make code little longer is not a big concern because on most of IDE you can just fold it off.
 
raj londonboy
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Tommy and Javin.

I think I got sufficient arguments and will be able to take decision on that basis:

  • Most of IDE gives warning for not using * - Its a standard
  • Code loses expressiveness
  • The compilation process can take even more time with a wildcard import statement
  • For improved readability, wildcard import statements are bad practice for anything
  • Any standard Java library doesn't contain wildchars in java files. - Apache and Sun libraries
  • The inconvenient aspects of explicit imports are minimized with modern IDEs. Most IDEs allow you to collapse the import section so it's not in the way, automatically populate imports when needed, and automatically identify unused imports to help clean them up.
  • Another explanation :Example


  • Thanks everyone once again for your inputs.
     
    Tommy Delson
    Ranch Hand
    Posts: 206
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Indeed there is a Compiling time hit when use the Wildcard (*), the Compiler has to scan the whole package for the class that use in the program. If you look in Chapter 10 K & B book on section that discussing about class with the same name in the different package and path.

    The Compiler will pick or choose the FIRST match so, if you use the Wildcard not specific name in the package what do you think the Compiler will pick?

    Is it the class that you use or the class with the same name in different package assumed you use these packages in your program. (This type of scenario is on the real exam as well, this is a good review.)



    In summary, try to limit the use of Wildcard as much possible especially in scenario I stated above. I think from now you have a clear
    decision to choose and what to do. :-)

    Oh, one important POINT that I didn't mention is that if you're using IDE (i.e Eclipse) in coding, using specific name is greatly benefit of finding the reference or link of other class on the "import" statement by place the cursor on the "import" and press F3 it will jump to the class that you use on the import assumed that everything created properly.

    There is no way the IDE can help find the reference of the class on the "import" if using the wildcard.




     
    Seetharaman Venkatasamy
    Ranch Hand
    Posts: 5575
    Eclipse IDE Windows XP Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Ulf Dittmer wrote:if you use "import ... *", then you are importing all classes from that package.


    in .class file there wont be any import statement instead compiler uses fully qualified name. and then when this classes from a package gets imported?
    https://coderanch.com/how-to/java/WildCardVsSpecificImports
    Please correct me, If i am wrong
     
    Ulf Dittmer
    Rancher
    Posts: 43081
    77
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Seetharaman Venkatasamy wrote:in .class file there wont be any import statement instead compiler uses fully qualified name. and then when this classes from a package gets imported?


    Imports are a source code concept; they are not applicable to class files. And yes, class files always deal with fully qualified names. I don't understand what you mean by the second question.
     
    Seetharaman Venkatasamy
    Ranch Hand
    Posts: 5575
    Eclipse IDE Windows XP Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Ulf Dittmer wrote: Imports are a source code concept;


    Hmm...when you see import ...* then we have to read as imports all classes. but it is different when javac come into picture!
     
    reply
      Bookmark Topic Watch Topic
    • New Topic