Disadvantage of using wildcards in import statement.

[Dipankar]

Hi,

Recently I wrote a certification test for Java2. There was a question
on using wildcards in import statement with four options. Only one
among them is correct (as per the test paper).
I was not very sure about the answer.

Can anyone help me in finding the answer?

Question

import java.util.*;

What is the disadvantage of using "*" in an import statement as shown
in the sample above?

Choice 1 : The class file is less portable.
Choice 2 : The Java Virtual Machine takes slightly longer to
validate the class file.
Choice 3 : The maximum number of classes allowed to be imported is
limited to 128.
Choice 4 : The code dependencies are difficult to evaluate from
reading the code.
Choice 5 : The Java Virtual Machine takes slightly longer to load the
class file.

According to me the Choice 4 is correct. But I am not sure about the
impact on JVM while using wildcards.

Thanks in advance.

 

[jiji]

Hi,

wildcards in import statement may slow down the compilation process. It
doesnt have any impact on performance of the application at run time.

Actually, the imported classes bytecode wont be bundled or included
with ur class. the import is more for resolving the actual class u r
refering in ur code..

~Jiji

 

[Patricia Shanahan]

Hi,

Recently I wrote a certification test for Java2. There was a question
on using wildcards in import statement with four options. Only one
among them is correct (as per the test paper).
I was not very sure about the answer.

Can anyone help me in finding the answer?

Question

import java.util.*;

What is the disadvantage of using "*" in an import statement as shown
in the sample above?

Choice 1 : The class file is less portable.
Choice 2 : The Java Virtual Machine takes slightly longer to
validate the class file.
Choice 3 : The maximum number of classes allowed to be imported is
limited to 128.
Choice 4 : The code dependencies are difficult to evaluate from
reading the code.
Choice 5 : The Java Virtual Machine takes slightly longer to load the
class file.

According to me the Choice 4 is correct. But I am not sure about the
impact on JVM while using wildcards.

Thanks in advance.

Java import statements are a compile time mechanism for mapping a simple
name such as "List" to a qualified name such as "java.util.List". I'm
not aware of any impact at all on the JVM.

Patricia

 

[Chris Smith]

Java import statements are a compile time mechanism for mapping a simple
name such as "List" to a qualified name such as "java.util.List". I'm
not aware of any impact at all on the JVM.

In fact, the JVM class file specification leaves little room for
compiled binary code to even contain any indications of what imports
were used in the source. Of course one can't specify that the
performance has to be equal -- so technically it's not guaranteed -- but
it would require something malicious for a compiler to actually generate
slower code due to imports.

 

[Neil Padgen]

Hi,

Recently I wrote a certification test for Java2. There was a question
on using wildcards in import statement with four options. Only one
among them is correct (as per the test paper).
I was not very sure about the answer.

Can anyone help me in finding the answer?

Question

import java.util.*;

What is the disadvantage of using "*" in an import statement as shown
in the sample above?

Choice 1 : The class file is less portable.
Choice 2 : The Java Virtual Machine takes slightly longer to
validate the class file.
Choice 3 : The maximum number of classes allowed to be imported is
limited to 128.
Choice 4 : The code dependencies are difficult to evaluate from
reading the code.
Choice 5 : The Java Virtual Machine takes slightly longer to load the
class file.

According to me the Choice 4 is correct. But I am not sure about the
impact on JVM while using wildcards.

Thanks in advance.

It's not just that code dependencies are difficult to evaluate: your
code might suddenly fail to compile.

Consider the following:

/* Bar.java */
package foo;

import java.util.*;

public class Bar {
public void baz() {
List ambiguousList = new ArrayList();
}
}
/* end Bar.java */

This compiles fine ... until I create a new class List in package foo.

$ javac *.java
Bar.java:7: incompatible types
found : java.util.ArrayList
required: foo.List
List ambiguousList = new ArrayList();
^
1 error

-- Neil

 

[ralf]

It's not just that code dependencies are difficult to evaluate: your
code might suddenly fail to compile.

Some long time ago I worked in a project that had it's own class
Currency. Then came JDK 1.4 and it's new class java.util.Currency. And
of course there were "import java.util.*" everywhere. We had to fix a
few hundert source files.

We used a script for that task (thanks sed), but it wasn't nice.

I think, with modern Java IDEs managing imports almost automatically,
there is no sound reason for using wildcard imports anymore.

Best regards,
Ralf.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Some long time ago I worked in a project that had it's own class
Currency. Then came JDK 1.4 and it's new class java.util.Currency. And
of course there were "import java.util.*" everywhere. We had to fix a
few hundert source files.

We used a script for that task (thanks sed), but it wasn't nice.

I think, with modern Java IDEs managing imports almost automatically,
there is no sound reason for using wildcard imports anymore.

Not in production code.

Code snippets to news groups maybe.



Wildcard imports should get shot down at the code
review.

Or even better by an automatic style checker run before
the code get into code review.

Arne

 

[Daniel Dyer]

Wildcard imports should get shot down at the code
review.

Or even better by an automatic style checker run before
the code get into code review.

IDEA has the option to optimise imports when it commits any changes to
version control. Your imports will be updated to match your configured
preferences (so expand wildcards and remove unused imports). Presumably
Eclipse has something similar (and NetBeans too)?

Dan.

 

[Guest]

IDEA has the option to optimise imports when it commits any changes to
version control. Your imports will be updated to match your configured
preferences (so expand wildcards and remove unused imports). Presumably
Eclipse has something similar (and NetBeans too)?

Interesting.

But I am so oldfashioned that I do not like if my code
is changed behind my back by a tool.

Arne

 

[IchBin]

Interesting.

But I am so oldfashioned that I do not like if my code
is changed behind my back by a tool.

Arne

Well I hate to tell you this but Eclipse and NetBeans can also
automatically build your import statements.

I am old fashioned too but it nice to use these tools for at least when
you open the program you can tell right upfront what classes the code is
using. For Eclipse it has been able to do this for more than two years.
Netbeans just added to their IDE.

So it is a proven functional part of a professional IDE.

 

[Guest]

Well I hate to tell you this but Eclipse and NetBeans can also
automatically build your import statements.

I am old fashioned too but it nice to use these tools for at least when
you open the program you can tell right upfront what classes the code is
using. For Eclipse it has been able to do this for more than two years.
Netbeans just added to their IDE.

So it is a proven functional part of a professional IDE.

I know and I use that feature all the time.

But it has very little in common with what I commented on.

I do not have a problem with the editor proposing
something that I can view and modify if I want to.

I have a problem if I look at the code, I think it is OK
and I choose commit and then the editor change the code.

Arne

co

 

[Karl Uppiano]

I know and I use that feature all the time.

But it has very little in common with what I commented on.

I do not have a problem with the editor proposing
something that I can view and modify if I want to.

I have a problem if I look at the code, I think it is OK
and I choose commit and then the editor change the code.

Arne

co

NetBeans does not automatically change import statements, but it will
generate them for you, and arrange them alphabetically. I never type import
statements by hand anymore. Net beans used to collapse down to wildcards
after 5 (configurable) imports from the same package. I don't think they do
that anymore.

 

[Stefan Ram]

Some long time ago I worked in a project that had it's own class
Currency. Then came JDK 1.4 and it's new class java.util.Currency. And
of course there were "import java.util.*" everywhere. We had to fix a
few hundert source files.

I believe that »Currency« should still refer to your local
class, unless you write »import java.util.Currency« without
the asterisk.

 

[Roedy Green]

One nice feature if the IntelliJ IDE is you can configure when to use
*. When you have fewer than that many packages, IntelliJ expands the
wildcard into individual classes, so you have an explicit list for
documentation. This gives a quick overview of what sorts of thing the
class does.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Patriotism is fierce as a fever, pitiless as the grave, blind as a stone, and as irrational as a headless hen."
~ Ambrose Bierce (born: 1842-06-24 died: 1914 at age: 71)

 

[Lew]

Some long time ago I worked in a project that had it's [sic] own class
Currency. Then came JDK 1.4 and it's new class java.util.Currency. And
of course there were "import java.util.*" everywhere. We had to fix a
few hundert source files.

I believe that »Currency« should still refer to your local
class, unless you write »import java.util.Currency« without
the asterisk.

This is resolved unambiguously in
<http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.5>

 

[Roedy Green]

This is resolved unambiguously in
<http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.5>

It is? I know you are a much better language lawyer than average. How
do you infer that from the statements there?
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Patriotism is fierce as a fever, pitiless as the grave, blind as a stone, and as irrational as a headless hen."
~ Ambrose Bierce (born: 1842-06-24 died: 1914 at age: 71)

 

[Lew]

I believe that »Currency« should still refer to your local
class, unless you write »import java.util.Currency« without
the asterisk.

Lew wrote, quoted or indirectly quoted someone who said:

It is? I know you are a much better language lawyer than average. How
do you infer that from the statements there?

Quoting the JLS chapter 7.5:

The example:

import java.util.*;

causes the simple names of all public types declared in the package java.util
to be available within the class and interface declarations of the compilation
unit. Thus, the simple name Vector refers to the type Vector in the package
java.util in all places in the compilation unit where that type declaration is
not shadowed (§6.3.1) or obscured (§6.3.2). The declaration might be shadowed
by a single-type-import declaration of a type whose simple name is Vector; by
a type named Vector and declared in the package to which the compilation unit
belongs; or any nested classes or interfaces.

It's the part about the type being declared in the same package or and nested
classes/interfaces shadowing the import-on-demand.

 

[Arne Vajhøj]

Some long time ago I worked in a project that had it's [sic] own class
Currency. Then came JDK 1.4 and it's new class java.util.Currency. And
of course there were "import java.util.*" everywhere. We had to fix a
few hundert source files.

I believe that »Currency« should still refer to your local
class, unless you write »import java.util.Currency« without
the asterisk.

This is resolved unambiguously in
<http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.5>

Even with specific rules in the JLS, then it is still bad for
readability.

Arne