Easiest question ever asked on EE:)

Whats the difference between :

import java.util.*;
import java.util.Vector;
If i am using only Vector class in my program then which one if efficient and why? Explain. Thes best explanation gets all points.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

the second is the best.

for two reasons:
1) compilation is faster (minutely) because the compiler search for names in a smaller nametable.
2) it is easier to read and understand your program, now that we know that Vector is the only class from java.util that you are using

regards JakobA
PS: the generated .class file is identical either way. as is the execution time for the compiled code.
> the second is the best.
the first is the best :)

> 1) compilation is faster (minutely) because the compiler search for names in a smaller nametable.

    who said it? i've never seen any diffenerences. do you read javac/jikes sources, so you can asure us ?

> 2) it is easier to read and understand your program, now that we know that Vector is the only class from java.util that you are using
  if you are using more than one or two classes from the same package, you import section growth too much.
   so, it's a question of style, your company used, use wildcards or no, in my experience there are more using wildcard style, than not.
Introduction to Web Design

Develop a strong foundation and understanding of web design by learning HTML, CSS, and additional tools to help you develop your own website.

>> dualsoul
    No I have not read the compiler source. the answer is based on general knowledge of compilers and the bewaviour of nametables. Even hashtables get increased response time as the number of entries grow. Not a lot (its an O(logN) ) so it is easy not to notice, but there is an increase.

It doesn't matter...

both JakobA, and dualsoul are right

1) it's easier if you are using more than one class from the same package to import all the classes in that package, it also keeps the java file shorter (for big classes)

2) it's easier to see what a class uses if you name them individually

The compile time is a red herring...  unless you exist on a higher plane, there is no difference ;-)
Package : java.util

Contains the collections framework, legacy collection classes, event model, date and time facilities, internationalization, and miscellaneous utility classes (a string tokenizer, a random-number generator, and a bit array).

Package : java.util.Vector

The Vector class implements a growable array of objects. Like an array, it contains components that can be accessed using an integer index. However, the size of a Vector can grow or shrink as needed to accommodate adding and removing items after the Vector has been created.

Each vector tries to optimize storage management by maintaining a capacity and a capacityIncrement. The capacity is always at least as large as the vector size; it is usually larger because as components are added to the vector, the vector's storage increases in chunks the size of capacityIncrement. An application can increase the capacity of a vector before inserting a large number of components; this reduces the amount of incremental reallocation.

Resources :


Hope it helps . . .
Intresting links


With due reference to mind proj from where I have copied
"It is a great help to understanding someone else's code, (or even your own), if you refrain from using the .* style of import with the imports giving you an explicit list of the classes you use in that class. The list of explicit imports gives you a rough idea of what the class could do and what it is likely up to. Don't leave unused imports lying around. Use an import tidier to get rid of them, and sort the valid ones into alphabetical order. During development, it is fine to use the lazy .* form, (doing so will save you a ton of compiler errors), but once your work gels, convert over. Bon't camouflage your use of classes by fully qualifying them and not reporting them in the import"

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Don't accept my comment as an answer...I think you should "Split Points" between JakobA and dualsoul :-)

(the split points link is just above the comment box) :-)


PS:  This is the easiest question ever asked on EE (IMO):


I just *love* CEHJ's answer :-)

>_< hee hee!
" Programming are bit good if you know how to implement not only the base classes but also the resources
  or the packages which handles the excution of your codes ".

Go on then, I'll add my comment ;-) ...

import java.util.*; gives you the permission to use any of the classes in the java.util package in your code.

import java.util.Vector; specifies that the *only* class you're going to use from the java.util package is Vector.

As has been said in various comments above:

Compilation speed is a red herring
The class file that is produced when you compile is identical regardless of which you use

As for which is best?  Well, that depends.  In this case, it makes absolutely no difference really, but, consider a classic problem that rears it's head from time to time on EE:

If you do the following:

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

Then you refer to List, the compiler tell you that there is a bit of a problem.  Do you mean java.awt.List (class) or java.util.List (interface).  In this case, if you only want the Vector from the java.util package, you would be better to name the class in your import rather than the package.

To be honest, I think that most Java developers would just use the .* on the end of their imports.  It's lazy, but if you need more that 2 or 3 classes from a package, the top of your file gets very messy very quickly if you try to name every class you use.

That's me done I think ;-)
>> If i am using only Vector class in my program then which one if efficient and why? Explain

import java.util.*;           -  It holds the primary package of the util class
import java.util.Vector;    -  You are specifying that you want to extend the vector class

If you use the " import java.util.*; " it will still extend to vector class because it is the package which
handles also vector.

Specifying " import java.util.Vector; " is also good because you are saying that you are only using
vector class.

Answer : The answer realy depends on you !

If you plan to use a lot of classes from the util classes then it is much better to use  " import java.util.*; " 
but if you only want to use the vector class then you should use  " import java.util.Vector; ".

Hope it helps . . .
the *easiest* question ???   Ha !

Anyway I think jimmack's point is extremely vell taken. Ther risk of identical names in the various packages become greater and greater as classes grow and as you include 3'rd party class libraries from Ibm, nokia, MS and thousands of other package developers.

regards JakobA

Duplicated class/interface names is the only circumstances that I have come across where real problems arise from the use of the .* notation.  I agree slightly with applekanna's point that listing individual classes/interfaces using import may give future developers clues as to the content of the class, but this is only really useful in very small classes.

Splitting the imports (in my experience) just turns into a code management nightmare, ie. remembering to remove those that you don't use any more, ensuring that new ones are added in the correct place (for readability, you should ensure that they are grouped by package) etc.
> Duplicated class/interface names is the only circumstances that I have come across where real problems arise

import java.util.* ;
import java.sql.* ;

Date f = new Date() ;

Being a perfect example :-)

Sleepy Tim
> ie. remembering to remove those that you don't use any more, ensuring that new ones are added in the correct place

JBuilder Enterprise can optimize them into either xxx.xxx.* or xxx.xxx.xxx

Very handy when you've done developing :-)

But for £3K I'd expect it to be handy ;-)
Indeed.  3-)
Tangential question:
  Should we root for a
doNotImport   xxx.xxx.Stack;                // any reference to 'Stack' is not that Stack
  line to supplement import ?
Hmm..  I never think about imports anymore since I use IntelliJ. If something is not imported, I just need to press ALT-ENTER, and it imports automatically. In the case of Vector I would add:

import java.util.Vector

if that is the only class I use from that package. As soon as I use more then 3 classes from the same package, it changes to:

import java.util.*

I find this very convenient.
> I find this very convenient.

Until you need java.util.* and java.sql.* (see my above post)
>import java.util.* ;
>import java.sql.* ;

>Date f = new Date() ;


import java.util.Date ;
import java.sql.Date ;

Date f = new Date() ;

does it help you? ;)))
> does it help you? ;)))

Hehehe, but you said;

> As soon as I use more then 3 classes from the same package, it changes to:
> import java.util.* ;

my example should have been:

import java.util.* ;
import java.sql.* ;

ArrayList a = new ArrayList() ;
Hashtable h = new Hashtable() ;
Iterator it = null ;
Connection conn = null ;
PreparedStatement ps = null ;
ResultSet rslt = null ;

Date d = new Date() ;

what does IntelliJ do in this situation?

hm...i said nothing about IntelliJ, i prefer ViM ;)))
Ahhh sorry...

Got confused...thought you were FesterWim for a moment there ;-)

> i prefer ViM ;)))



It will show the dialog that an import is needed and you can choose between java.util.Date and java.sql.Date.

If you then select for instance java.util.Date, the imports will change to:

import java.util.*;
import java.util.Date;
import java.sql.*;
Does that work?

Cool :-)
Yep, it does work. I tried it before posting :)
Cool :-)

Isn't EE great?
cool if and only if if javas rules for resolving names expressly specify that that will cause java.util.Date to be the 'Date' found.

if they do not you are merely exploiting an implementation dependent quirk that may be different in the next version of whichever java-compiler you are using. Usually not the best thing to do.

So I looked it up hoping that there would be no such specification.
The language rules do specify this ( 7.5 in http://java.sun.com/docs/books/jls/second_edition/html/packages.doc.html ). The single-type-import declaration is shadowing the Type-Import-on-Demand Declarations of the type 'Date'.
    import java.util.*;
    import java.util.Date;
    import java.sql.*;
is really leagal.

But I hate it anyway :)
Igor BazarnyCommented:
Code is written once, but after that it's read and changed many times by different people. It means to me that code should be optimized for READING. And when I read and see unknown short class name I often want to know full name for that class. So IMO it may be OK to have one-2 .* imports, or import standard packages using .* form, but not more. As long as we are too lazy, I put more straigthforward restriction on myself and almost never use .* imports. To control import list length I keep my classes small.
I set .* import limit to at least 10 when use IDEA. And I'm quite happy with simplest text editors, entering my imports by hand or copying from javadoc.

I have to say with the opinion (whoever it was) that * whilst developing, then fully qualified when dev finishes seems like the best of both worlds :-)

For the easiest question...this seems to have gone on for ages ;-)

And where's b_vishwajit?

Hope we didn't scare him off :-)
I haven't read all the comments but I will say the following :

  If you use the         import java.util.*
 you will not notice if it is slower than using the other because compiler isn't so slow !
 But it is not recomended because you will slow it down ! It is based on the amount of search resources that are used to add every libs while using           import java.util.Vector        is much more smarter because you will get faster compilation (you want noticed it if you aren't runnnig slower machine) and more bug unlike code - if you use more than vectors ofcourse !
If you use the second it is smarter not because of other reason than simplification ! Much more simpler and faster and nothing unnecessery in the code of your project !!!

Well remember that simpler code is  :
 1. better !
 2. faster !
 3. powerful !
 4. understandable for modification !
 5.  tell me what I'm wrong about !!!!!!          ;-)

Regards !

---  OpenSource rulles the world !   ---
----  Human knowledge belongs to the world !   ----
> Wheeee!

> [i]cool[esc][Shift-ZZ
 Tim, it's a joke :)), but when i have to write many code manually i prefer text mode editor, not graphical, just to save my eyes :)

> I have to say with the opinion (whoever it was) that * whilst developing, then fully qualified when dev finishes
 hm...you know, there are many projects, that are in developing mode every time, even after deploying, new functionaloty adding and so on and so on ... so maybe it's better to have ......*; form? :)

>you want noticed it if you aren't runnnig slower machine
   Java is only for fast machines :))) LOL

so much interesting was said here, but where is the author's opinion? :)
b_vishwajitAuthor Commented:
>>And where's b_vishwajit?
Hope we didn't scare him off :-)<<

Lol I was not getting enough time to close this simple question. I dont want to be unfair while I close my question though none of you care.That was quite a good input from you people.Thanks everyone and sorry for the delay.
Thx :)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.