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.

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

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

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 HereWEBlog

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.

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

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

posted Oct 20, 2004 22:16:00

0

'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

posted Oct 20, 2004 22:23:00

0

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

posted Oct 21, 2004 00:24:00

0

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

posted Oct 21, 2004 01:52:00

0

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

posted Oct 21, 2004 16:41:00

0

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.

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

posted Oct 21, 2004 19:17:00

0

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

posted Oct 22, 2004 13:03:00

0

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

posted Oct 22, 2004 13:11:00

0

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.