Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / February 2006

Tip: Looking for answers? Try searching our database.

to use import java.lang.* or import java.lang.Math or none at all?

Thread view: 
JPractitioner - 20 Feb 2006 12:06 GMT
Hi guys,
i knew that by default all java.lang classes will be imported by the
compiler during compilation. but, to make it easier for the computer,
should i specify which class i really will be using? does this action
will boost the performance during compilation and runtime or not a
matter at all?

the answer to this post will definitely affect my programming style in
the future when i'm considering "to import or not to import"...
hmm,,,

thanks in advance.
Chris Uppal - 20 Feb 2006 12:31 GMT
> i knew that by default all java.lang classes will be imported by the
> compiler during compilation. but, to make it easier for the computer,
> should i specify which class i really will be using? does this action
> will boost the performance during compilation and runtime or not a
> matter at all?

Whether and how you import classes has exactly zero effect at runtime.  Imports
(with or without wildcards) are only a kind of abbreviation provided by the
compiler to save us the effort of typing in fully-qualified type names every
time.

In theory explicit importing should make compilation faster -- by a very tiny
amount.  I've never heard anyone claim that they've even managed to measure a
difference let alone found a case where it made a practical difference.

So the question comes down to how to write your code for maximum clarity.  One
school of thought asserts that you should always import each class explicitly
(rather than by a wildcard).  There's a fair consensus on that point -- with
which I disagree.  For some reason, the advocates of that point of view seem to
exclude classes in the java.lang package.  I agree entirely that it would be
counter-productive to be explicit about importing those classes -- I just
extend the logic to other well-known packages where they fail to do so ;-)

Still, that /is/ the consensus, so -- unless you prize "best practice" over
"common practice" (and there are arguments to be made for both positions) --
you won't go /too/ far wrong by falling in with the crowd, and your life may be
a little easier.

   -- chris
Thomas Weidenfeller - 20 Feb 2006 12:40 GMT
> Still, that /is/ the consensus, so -- unless you prize "best practice" over
> "common practice" (and there are arguments to be made for both positions) --
> you won't go /too/ far wrong by falling in with the crowd, and your life may be
> a little easier.

I only see it as "consensus" among people using certain IDE's who happen
to shout loudest and among some book authors. The later often of the
type where, by judging them by their books, they have never written any
program larger than Hello World.

/Thomas

Signature

The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/

Raymond DeCampo - 20 Feb 2006 14:28 GMT
>> Still, that /is/ the consensus, so -- unless you prize "best practice"
>> over
[quoted text clipped - 7 lines]
> type where, by judging them by their books, they have never written any
> program larger than Hello World.

And among people who do not like to risk having their code fail to
compile when third parties add classes to their packages.

Ray

Signature

This signature intentionally left blank.

Chris Uppal - 20 Feb 2006 14:46 GMT
> > Still, that /is/ the consensus, so -- unless you prize "best practice"
> > over "common practice" (and there are arguments to be made for both
[quoted text clipped - 3 lines]
> I only see it as "consensus" among people using certain IDE's who happen
> to shout loudest and among some book authors.

<grin>

There is something in what you say ;-)

   -- chris
Roedy Green - 24 Feb 2006 20:47 GMT
On Mon, 20 Feb 2006 13:40:14 +0100, Thomas Weidenfeller
<nobody@ericsson.invalid> wrote, quoted or indirectly quoted someone
who said :

>I only see it as "consensus" among people using certain IDE's who happen
>to shout loudest and among some book authors. The later often of the
>type where, by judging them by their books, they have never written any
>program larger than Hello World.

With Eclipse or IntelliJ to deal with imports, I am very glad of it to
maintain and explicit list with no deadwood.  This is a great help in
coming back to code cold.  A quick look at at the imports narrows down
immediately what sort of things a class COULD  be up to.

While coding I use lots of *s, and let Eclipse tidy them up later. No
point in me manually typing out all the names.  Earlier, in SlickEdit,
I had a macro to dump the kitchen sink in there, which I later tidied
out with a utility.

I have written quito a bit on how I think you should do this.  See
http://mindprod.com/jgloss/import.html
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Thomas Weidenfeller - 20 Feb 2006 12:36 GMT
> i knew that by default all java.lang classes will be imported by the
> compiler during compilation. but, to make it easier for the computer,
> should i specify which class i really will be using?

No.

> does this action
> will boost the performance during compilation and runtime or not a
> matter at all?

No.

> the answer to this post will definitely affect my programming style in
> the future when i'm considering "to import or not to import"...

Are you that easy to convince? I have that lovely bridge on sale ... ;-)

/Thomas
Signature

The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/

tom fredriksen - 20 Feb 2006 17:26 GMT
>> does this action
>> will boost the performance during compilation and runtime or not a
>> matter at all?
>
> No.

I know you are saying no. But to expand the question a bit.
Does this affect in any way how fast the jvm starts up? considering the
long list of classes loaded when the jvm start. I would logically think
that reducing the number of classes read in that list would at least
affect the startup time. Especially when using lots of third party
libraries, which might be quite large. Further on the question can be
expanded to adding large jars in the classpath, how does that affect
both startup time and other aspects.

Is the answer still no? I know it has to touch the file/class anyway to
be able determine if its something to use, but does that mean no extra
cost after that?.

/tom
JPractitioner - 20 Feb 2006 18:00 GMT
yeah, i am using third party jars as well, good one tom :)
Daniel Dyer - 20 Feb 2006 19:56 GMT
>>> does this action
>>> will boost the performance during compilation and runtime or not a
[quoted text clipped - 7 lines]
> affect the startup time. Especially when using lots of third party  
> libraries, which might be quite large.

The import statement only has an impact at compile time.  The generated  
class file will be the same whether you use wildcard imports or specify  
each class individually.  The class file will have no reference to classes  
that you have imported but not actually used.

Dan.

Signature

Daniel Dyer
http://www.dandyer.co.uk

Chris Uppal - 20 Feb 2006 20:01 GMT
>[...] to expand the question a bit.
> Does this affect in any way how fast the jvm starts up?

Depends whether you are asking about import statements or the classes
themselves.

If you are asking about imports then they have /no/ effect on /anything/ at
runtime.  Zero.  Simply because no information about imports is retained in
.class files -- all class references are resolved into fully-qualified names by
the compiler.  That applies to explicit imports of specific classes, to
wildcard imports, and to the implicit import of java.lang.*.

> considering the
> long list of classes loaded when the jvm start. I would logically think
> that reducing the number of classes read in that list would at least
> affect the startup time.

OTOH, the more classes that have to be loaded, the longer it will take.  But
it's only classes that are actually used or referred to (e.g. as the type of a
method's parameter) that have to be touched at all (imports, as I said above,
don't matter).  The JVM is allowed a fair amount of leeway in postponing these
activities for as long as it decently can, but -- obviously -- the more classes
are directly involved in, or needed by, your app's startup, the longer that
startup will take.

> Especially when using lots of third party
> libraries, which might be quite large. Further on the question can be
> expanded to adding large jars in the classpath, how does that affect
> both startup time and other aspects.

The number of classes on the classpath can certainly have an effect on the time
it takes to locate a class.  Imagine a classpath with a couple of hundred
million JAR files for instance -- it'd be kinda slow, and might not fit in
memory at all ;-)  Also the bigger the JAR the more memory it takes to store
the table of contents.  So lots of large JARs might have a detectable effect.
But note that any sensible classloader implementation will build some sort of
fast lookup (hash table, or whatever) so the chances are that actually locating
classes will not be a significant factor in the time it takes to load them.

Some of the performance tweaking that has gone on between 1.4, 1.5, and what
(little) I know of 1.6, has revolved around optimising the way that classes are
loaded at startup, and how best to balance speed with memory requirements for
loading JARs.

   -- chris
Roedy Green - 24 Feb 2006 20:48 GMT
>I know you are saying no. But to expand the question a bit.
>Does this affect in any way how fast the jvm starts up?

You missed the point. The import list is NOT a list of classes to
load.  It is list of to help expand short names in the code to fully
qualified ones. The only classes that get loaded are the ones you
actually use.

See http://mindprod.com/jgloss/import.html

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

steve_marjoribanks@hotmail.com - 20 Feb 2006 13:03 GMT
It's up to you really. Different people have different styles. As far
as I know, importing in groups won't slow it down or make it larger but
it does make it less obvious to anyone else who reads your code as to
exactly which classes the methods you've used have come from.
JPractitioner - 20 Feb 2006 13:46 GMT
Thanks all for the replies..
since there will be no affect on performance during runtime,
i'll be hapier using the wildcards..
but the idea of making it more obvious to other peoples(clarity
purposes) is good
hehe, thomas, actually it depends on how satisfying the answers i'm
getting..
sorry to not mentioning that :D
by the way, how much is the bridge?

Thanks again all.
Cheers.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.