File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes import pkg.* vs. import pkg.class Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "import pkg.* vs. import pkg.class" Watch "import pkg.* vs. import pkg.class" New topic
Author

import pkg.* vs. import pkg.class

Victor Ho
Ranch Hand

Joined: Sep 05, 2003
Posts: 74
Hi,

I am wondering, in terms of runtime behavior/performance, what would be the differences for doing import pkg.*; vs. import pkg.class;?

In terms of code maintanence, I would say "import pkg.class;" is a better practice due to that it is easier for other developers to look up which exact package a class belongs to.

But in terms of what actually happens at runtime, does it make any difference? Will "import pkg.*;" cause the class loader to load all classes at runtime?

Which is a better practice in general?

Thanks
Victor
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

You'll have to check this (because its been a while since I did) but as I remember, it used to be considered more performant to explicitly import only those classes which you use. But now I don't think it makes much of a difference. I much prefer explicitly importing classes, since I find its much clearer.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
It never made any difference. Imports are fully resolved at compile time - the byte code invariably contains fully qualified class names.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Nyasha Chirara
Greenhorn

Joined: Oct 18, 2004
Posts: 1
packages and classes are resolved at compile time duh
somkiat puisungnoen
Ranch Hand

Joined: Jul 04, 2003
Posts: 1312
In my opinion,

import pkg.class;

It's better than import pkg.*;

Because your code is readability, easy to maintain code.


SCJA,SCJP,SCWCD,SCBCD,SCEA I
Java Developer, Thailand
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Originally posted by somkiat puisungnoen:
In my opinion,

import pkg.class;

It's better than import pkg.*;

Because your code is readability, easy to maintain code.


but I read in a book(Which I can't remember) that performance is not different between the two usages...

Any other comments on the performance issue are welcome...


Co-author of SCMAD Exam Guide, Author of JMADPlus
SCJP1.2, CCNA, SCWCD1.4, SCBCD1.3, SCMAD1.0, SCJA1.0, SCJP6.0
Arun Prasath
Ranch Hand

Joined: Sep 17, 2003
Posts: 192
yes, I dont think there is any performance difference between the two.

But using
import package.class1
import package.class2

tells what all the specific classes that are used in the program rather than the packages that are used. I follow this, as it increases the readability to the user.


SCJP 1.4, SCDJWS , SCJA<br />I can do ALL things through CHRIST who strengthens me.
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Originally posted by Arun Prasath:
yes, I dont think there is any performance difference between the two.

I think the importing is done only to the classes used in the source code.... Or is it importing all available classes in the package as default, whichever methods we use....

Thanks for your opinions...
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

There is no performance harm when you import package.*.


Groovy
Don Kiddick
Ranch Hand

Joined: Dec 12, 2002
Posts: 580
It will take longer to compile though
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Originally posted by Don Kiddick:
It will take longer to compile though


Could you explain a bit more about your sentence? Thanks...

Because I am always thinking that both usages matter just to readibility issue and nothing else...
somkiat puisungnoen
Ranch Hand

Joined: Jul 04, 2003
Posts: 1312
Remark On IDE::

Organized import ::
- Eclipse use full import like java.util.Date;
- JBuilder use * import like java.util.*;
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Originally posted by somkiat puisungnoen:
Remark On IDE::

Organized import ::
- Eclipse use full import like java.util.Date;
- JBuilder use * import like java.util.*;


I think that is just IDE designers' favourites... Eclipse might emphasize on readibility issue, while JBuilder emphasize on convenience. Specifying with * might help us not to import every other classes in the package one by one, if we need to use many classes from that package... But it can affect the readibility issue of the code... So that's just a trade-off...
Senthil B Kumar
Ranch Hand

Joined: Feb 09, 2004
Posts: 140
Adv of import pkg.class when compared to pkg.*;

1) Readabiliy and Clarity, allows the developers to know what are the classes they are dealing with really.
2) Avoids confusion
eg. pkg1 has a class called A and pkg2 has a class called A & B. you are using classes A in pkg1 and B in pkg2.now if u do import * for both pakcages and try to create an object for class A, there would be a compilation error. this kind of situation is avoided by importing only the required classes.

3) When it comes to performance, yes it does affects the performance,not while execution but while compilation. Once its compiled java files with import * and importing specific classes only will be executing with same performance. the performance issue comes only during compilation.


Work like you don't need the money. Love like you've never been hated. Dance like nobody's watching. Sing like nobody's listening. Live like it's Heaven on Earth.
Currently I Reside Here WEBlog
Stefan Wagner
Ranch Hand

Joined: Jun 02, 2003
Posts: 1923

Did someone ever measure the performance, which is told to be smaller when using
import foo.* ?
3000 Classnames can be effectively be stored in a hash.
And parsing multiple 'import' - statements isn't for free.
I guess the statement needs some proof.

About readability: 20 import javax.swing.foo; - statements isn't readable.

And name collisions only occure on random dates.

In Eclipse you may configure, whether to use single import statements, or the number, from which to use the asterix, which may be '2'.


http://home.arcor.de/hirnstrom/bewerbung
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
The only performance issue is that a source file with wildcard imports will compile slower, and the performance of your code maintainers will decrease.
As already mentioned, there is no runtime performance effect.

This can be proven by taking a source file with wildcard imports, compiling it to one or more class files; then take the same source file, changing the imports to be fully qualified; and compiling it to another set of class files. Then play "spot the difference" (or /usr/bin/diff).

You'll find that there are 0 differences.


Tony Morris
Java Q&A (FAQ, Trivia)
Joyce Lee
Ranch Hand

Joined: Jul 11, 2003
Posts: 1392
SW:About readability: 20 import javax.swing.foo; - statements isn't readable.

In this case, if the 20 classes are from the same package, I would go for asterisk. Otherwise, I would prefer "import pkg.class" style.

Joyce
[ October 21, 2004: Message edited by: Joyce Lee ]
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
'readable' is not the only argument.
General good style outlaws wildcard imports altogether.
There is good reason for this.

Consider a source file that uses a few third-party APIs (as is often the case in source that I read at work; your scenario may differ).

In the source file you have the following:



Your job now is to read the documentation for these two classes.
You will have to first find which package it belongs to.
Read the bytecode? Comment an import statement until the compiler complains? (not possible if you aren't given compilable source as is often the case).

The case becomes worse when you take the above example and apply it in practice. Often, there are more than 3 third-party APIs and a whole lot more than 2 'stray' classes.

How much easier is this kind of code to 'read' when the wildcard imports are gone?
I'll let you be the judge.
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Originally posted by Stefan Wagner:
Did someone ever measure the performance, which is told to be smaller when using import foo.* ?

This could be a good research on Java... Some kinda benchmark performance should be done on this issue...

Well, I can't really figure out which book that I read... That book says there is no performance harm in those two usages...
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
There is nothing to test.
The bytecode is precisely the same.
How can two bytecode files that contain the exact same content not have equal performance?

As already mentioned, the only performance impact is that of the compiler (to resolve the location of source files) and of your code maintainers (since wildcard imports reduce maintainability).
somkiat puisungnoen
Ranch Hand

Joined: Jul 04, 2003
Posts: 1312
Does using * in an import statement affect performance?

This question has come up a surprising number of times in various forums. The question relates to the import directive, as in

import java.util.*;

The short answer is: no, 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.

In fact, 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
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608

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


To be absolutely clear, I cannot agree with the last point.
It is unsubstantiated (at least, given the information on this thread) as is a little out of context.
I'd speculate that it is untrue, but that too is unsubstantiated (as per the definition of a speculation of course ).

Do you have anything to support it?
I'd suggest omitting it from 'the complete answer' unless it can be proven or disproven.
Stefan Wagner
Ranch Hand

Joined: Jun 02, 2003
Posts: 1923

When I wrote:
Did someone ever measure the performance, which is told to be smaller when using
import foo.* ?

I was of course talking about compile-time performance.
I think this is pretty clear, if you read the next sentences:

3000 Classnames can be effectively be stored in a hash.
And parsing multiple 'import' - statements isn't for free.
I guess the statement needs some proof.


Tony:
When I don't know where SomeNonCoreClass or SomeOtherClass comes from, I right-click on my mouse in eclipse, and I know, while you're scrolling up to find the import-statement.

Giving the judge back to you.

somkiat:
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.

Wow! So if I use: import java.util.*; the compiler unzips classes.zip, recompiles java.util.*, and updates rt.jar?
If this isn't true, why should it be true at all - be true for import stefan.tools.ranchconfuser.*;?

Well - why speculate on the truth, if we may test it?

Here is my code:


While only using java.util.ArrayList, I let the compiler search in some additional small packages. If the compiler looks up in the same order, as specified in the source-code, it will find the right package at last.

The second test is without all that packages, just the commented import statement.
In this nearly worst-case scenario, running a jdk 1.4 on a 1.1 Ghz machine it takes to compile:


with jdk-1.5:

600 compilations cost one additional minute.
That's something I will live with comfortable.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608

When I don't know where SomeNonCoreClass or SomeOtherClass comes from, I right-click on my mouse in eclipse, and I know, while you're scrolling up to find the import-statement.

Giving the judge back to you.


And if the source (or even binaries) to these classes is not available (as is often the case)?
What does Eclipse tell you then?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Tony Morris:


And if the source (or even binaries) to these classes is not available (as is often the case)?
What does Eclipse tell you then?


Having no source doesn't make any difference. Having no binaries would give you a compile error, of course. :shrug:
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
With modern IDE's, I don't take a look at imports any more, so readability isn't an issue for me.

What is an issue, though, is maintainability - and that is better with non-wildcard imports.

Imagine you are using two libraries, foo and bar, and use classes from both libraries.

import foo.*;
import bar.*;

You are using class Node from library foo. Now you update the bar library to a newer Version, and it happens that they added a Node class, too. Suddenly, your code doesn't compile anymore due to the ambiguity. And if the developer who has to resolve the problem isn't familiar with the code, he might have to do some research to find out what needs to be done.

And yes, that happens. I had to find out the hard way...
crisis ofid
Greenhorn

Joined: Oct 22, 2004
Posts: 5
can anyone tell me how to stop a program running in background
Stefan Wagner
Ranch Hand

Joined: Jun 02, 2003
Posts: 1923

No, this isn't the bus to central-station, lady.
Stefan Wagner
Ranch Hand

Joined: Jun 02, 2003
Posts: 1923

Ilja: The later changed class is an argument.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
As this is a recurring question, I created a FAQ entry: http://faq.javaranch.com/view?WildCardVsSpecificImports
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Originally posted by Ilja Preuss:
As this is a recurring question, I created a FAQ entry: http://faq.javaranch.com/view?WildCardVsSpecificImports


Ilja, I do appreciate your help on creating this issue as an FAQ... By now, we don't need to argue the same old thing again and again anymore, but forward to that FAQ...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: import pkg.* vs. import pkg.class