b_vishwajit
asked on
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.
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.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
PS: the generated .class file is identical either way. as is the execution time for the compiled code.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>> 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.
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.
1)
2)
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 ;-)
2)
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 :
http://java.sun.com/j2se/1.3/docs/api/java/util/package-summary.html
http://java.sun.com/j2se/1.3/docs/api/java/util/Vector.html
Hope it helps . . .
JAVATM
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 :
http://java.sun.com/j2se/1.3/docs/api/java/util/package-summary.html
http://java.sun.com/j2se/1.3/docs/api/java/util/Vector.html
Hope it helps . . .
JAVATM
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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) :-)
Tim
PS: This is the easiest question ever asked on EE (IMO):
https://www.experts-exchange.com/questions/20451017/Where-can-I-find-good-swing-problems-on-net.html
I just *love* CEHJ's answer :-)
>_< hee hee!
(the split points link is just above the comment box) :-)
Tim
PS: This is the easiest question ever asked on EE (IMO):
https://www.experts-exchange.com/questions/20451017/Where-can-I-find-good-swing-problems-on-net.html
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 ".
Javatm
or the packages which handles the excution of your codes ".
Javatm
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>> 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 . . .
JAVATM
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 . . .
JAVATM
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
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 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.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
> 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 ;-)
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 ?
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.
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)
Until you need java.util.* and java.sql.* (see my above post)
>import java.util.* ;
>import java.sql.* ;
>Date f = new Date() ;
hm....
import java.util.Date ;
import java.sql.Date ;
Date f = new Date() ;
does it help you? ;)))
>import java.sql.* ;
>Date f = new Date() ;
hm....
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?
Tim
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?
Tim
hm...i said nothing about IntelliJ, i prefer ViM ;)))
Ahhh sorry...
Got confused...thought you were FesterWim for a moment there ;-)
> i prefer ViM ;)))
Wheeee!
[i]cool[esc][Shift-ZZ]
;-)
Got confused...thought you were FesterWim for a moment there ;-)
> i prefer ViM ;)))
Wheeee!
[i]cool[esc][Shift-ZZ]
;-)
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.*;
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 :-)
Cool :-)
Yep, it does work. I tried it before posting :)
Cool :-)
Isn't EE great?
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.
Alas.
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 :)
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.
Alas.
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 :)
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
True...
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 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 ! ----
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? :)
> [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? :)
ASKER
>>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.
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 :)