6

Possible Duplicate:
Why is using a wild card with a Java import statement bad?

Ex. 1

import javax.swing.*

JFrame f = new JFrame()

Ex. 2

import javax.swing.JFrame

JFrame f = new JFrame()

Is there any efficiency gain (even the slightest and minimal) in adapting 2) instead of 1) ? How does java does the referencing of packages internally?

The first time the compiler comes across the word JFrame, I presume that it should search for JFrame in complete swing.* package in case of 1)..Else if in case 2), it might probably get hold of the class directly by some indexing or may be key value hashing? So why is this not considered an efficiency gain even if it is tiny? (Please correct me if my presumptions about the internals are wrong)

EDIT :

Sorry for the duplicate.. Answer at Why is using a wild card with a Java import statement bad?

Community
  • 1
  • 1
Vamsi Emani
  • 10,072
  • 9
  • 44
  • 71
  • 1
    Well as stated in one of many answers on SO it clutters the your local namespace (http://stackoverflow.com/questions/147454/why-is-using-a-wild-card-with-a-java-import-statement-bad). – Pieter Dec 06 '11 at 14:30

6 Answers6

11

There is no runtime penalty for using import javax.swing.* and import javax.swing.JFrame in Java. The only different is in compile time, the import package.* will search for whole package to find the correct class' information.

The Single-Type-Import (e.g., import javax.swing.JFrame) increases the readability of the program and it will be very clear which classes have been used.

The Type-Import-on-Demand (e.g. import javax.swing.*) causes the simple names of all public types declared in the package javax.swing to be available within the class and interface declarations of the compilation unit.

Noufal Panolan
  • 1,357
  • 2
  • 14
  • 27
3

the first one will load all classes in the package at the compile time 

Ex : 1

import javax.swing.*

JFrame f = new JFrame()

the second will load only class specified at the compile time 

Ex: 2

import javax.swing.JFrame

JFrame f = new JFrame()

it will increase the compile time if you use the first approach

confucius
  • 13,127
  • 10
  • 47
  • 66
  • I also think there is a slight chance of increased compile time, but making a test for compiling using either javax.swing.JFrame or javax.swing.* (and several other wildcard imports) I could not get any statistical significant data. – Roger Lindsjö Dec 06 '11 at 14:43
1

The star notation is merely a convenience so you as a programmer don't have to write tons of import statements. The star notation will include all classes of the specific package as a compilation candidate.

Note that in most cases being specific is preferred as it will clearly expresses your intention. Furthermore, modern IDE's will do the tedious bit of import statements for you. So in a way you can consider the star notation rather obsolete.

M Platvoet
  • 1,679
  • 1
  • 10
  • 14
0

It has performance issue at compile time as others said (may not be very significant one considering the processing power of current computers). ie., importing * make the compiler need to look in entire package, while importing a specific class allows the compiler to fetch it directly. But it doesn't cause any performance issues at run-time, because all classes will be correctly linked by the compiler after compilation.

It also has something to do with readability. If we import javax.swing.*, it will be difficult for us to know which classes are being used from the package javax.swing. We need to read the program to find it out. But, if we import specific classes like import javax.swing.JFrame, it will help the reader to understand only the specified classes are being used from outside packages. Here we know that only JFrame is used from the package javax.swing without reading the entire program. ie., the one can find the dependencies required by our program easily by looking at the import section.

Another problem is that you may get into naming conflicts. For example, if you do two imports import com.abc.* and import com.xyz.*. Now, assume that both packages contain a class named SomeClass. Then, it put the compiler into an ambiguous situation as to which SomeClass to be imported, and thus it will result in a compile time error.

Jomoos
  • 12,823
  • 10
  • 55
  • 92
0

Apart from that Ex.2 is more explicit and thus clearer, it's also more stable/ compatible.

E.g. consider

import java.awt.*;
import java.util.*;

...

List list;

in pre-collection days. If you run the same code with a jdk version which has collections, the compiler complains as it doesn't know which List to use.

As others said, IDEs will help you organize the import statements.

Puce
  • 37,247
  • 13
  • 80
  • 152
-1

Yes. 

import javax.swing.*

imports all classes within this package.

import javax.swing.JFrame

imports only JFrame class.

I would suggest importing concrete classes. Regards!

Mechkov
  • 4,294
  • 1
  • 17
  • 25
  • This should not affect performance at all (maybe it broadens the namespace needed by the compiler to search so compilation could take slightly longer). It is just for convenience. – Roger Lindsjö Dec 06 '11 at 14:37
  • I may be incorrect at this, but I *believe* that this imports the *names into your namespace* only. The compiler uses this for build-time name resolution. At run-time, the full class names are included in your `.class` file, regardless, and only for those classes which are actually used. So, while there are issues with regards to software maintenance preferences, as well as the obvious namespace “cluttering,” it should have no effect upon the final binaries. – BRPocock Dec 06 '11 at 14:38
  • I don't think it has any impact on performance. – Russell Dec 06 '11 at 14:43