import pkg.* vs. import pkg.class

[Victor Ho]

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]

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.

[Ilja Preuss]

It never made any difference. Imports are fully resolved at compile time - the byte code invariably contains fully qualified class names.

[Nyasha Chirara]

packages and classes are resolved at compile time duh

[somkiat puisungnoen]

In my opinion,

import pkg.class;

It's better than import pkg.*;

Because your code is readability, easy to maintain code.

[Ko Ko Naing]

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

[Arun Prasath]

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.

[Ko Ko Naing]

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]

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

[Don Kiddick]

It will take longer to compile though

[Ko Ko Naing]

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]

Remark On IDE::

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

[Ko Ko Naing]

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]

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.

[Stefan Wagner]

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'.

[Tony Morris]

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.

[Joyce Lee]

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]

'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:

import api.from.joe.*;
import api.from.blow.*;
import api.from.toe.*;
 
class X extends SomeNonCoreClass
{
    private SomeOtherClass t;
}

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]

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]

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]

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]

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]

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:

import java.io.*;
import java.awt.*;
import javax.swing.*;
import java.math.*;
import java.util.*;
 
// import java.util.ArrayList;
 
public class Foo
{
public Foo ()
{
ArrayList al = new ArrayList ();
}
}

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:

fully qualified    0m1.509s
wildcard usage     0m1.643s

with jdk-1.5:

fully qualified    1.4s
wildcard usage     1.5s

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

[Tony Morris]

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]

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]

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]

can anyone tell me how to stop a program running in background

[Stefan Wagner]

No, this isn't the bus to central-station, lady.

[Stefan Wagner]

Ilja: The later changed class is an argument.

[Ilja Preuss]

As this is a recurring question, I created a FAQ entry: http://faq.javaranch.com/view?WildCardVsSpecificImports

[Ko Ko Naing]

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

[Felipe Carasso]

Reviving this old discussion.

I came across a situation where a class uses constants from another class for text labels. These classes are tightly connected.

What would you prefer?

import static com.something.something.something.something.something.something.something.Label1
import static com.something.something.something.something.something.something.something.Label2
(...) x20

or...
import static com.something.something.something.something.something.something.something.*

?

[Guillermo Ishi]

Felipe Carasso wrote:Reviving this old discussion.

I came across a situation where a class uses constants from another class for text labels. These classes are tightly connected.

What would you prefer?

import static com.something.something.something.something.something.something.something.Label1
import static com.something.something.something.something.something.something.something.Label2
(...) x20

or...
import static com.something.something.something.something.something.something.something.*

?

The only problem with wildcards is possible name collision in the future. In cases where you were dealing with the java class library you could probably assume that would never be a problem.

[Campbell Ritchie]

Welcome to the Ranch

There are some people who think static imports are absolutely wonderful and some who think they should be avoided at all costs. What if you import two classes which have the same‑named static field or static method? If you use the on‑demand import style, you will get an ambiguity. And, despite what people say, you should never make assumptions. The class you have imported a static member from might acquire a member with a name collision with another class in future. Then you get the Node problem again, only this time it becomes the canEqual problem.

[Stephan van Hulst]

I really think this is a non-issue. Do whatever you prefer, or whatever your company prescribes. I like to use wildcard imports because it's quicker for me. If something doesn't work because there's ambiguity, or I imported the wrong class, it usually clears up at compile time. People probably waste more time arguing about this than they do trying to find the correct class from source code.

[Tim Holloway]

I'm towards the other end of the spectrum. Pulling in via wildcard means that things can be accidentally grabbed that shouldn't be grabbed. If there are blurs or duplications of simple class names then rotten typists like me can end up wasting a day or two discovering that what I was getting wasn't what I thought I was asking for.

Regardless, if you're using an IDE, be aware that some IDEs can swap back and forth between wildcard and specific packages automatically and without warning when you tidy up code. It won't make a difference in how the class compiles or runs, but if you're obsessive about this kind of stuff, you may find it annoying.

[Campbell Ritchie]

I have had problems with Eclipse changing import com.campbell.resources.MyClass.*; to named fields imported and wondered why I can't find a particular number.