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

J

JPractitioner

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.
 
C

Chris Uppal

JPractitioner said:
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
 
T

Thomas Weidenfeller

JPractitioner said:
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
 
T

Thomas Weidenfeller

Chris said:
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
 
S

steve_marjoribanks

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.
 
J

JPractitioner

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.
 
R

Raymond DeCampo

Thomas 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.

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

Ray
 
C

Chris Uppal

Thomas said:
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
 
T

tom fredriksen

Thomas said:

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
 
D

Daniel Dyer

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.

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.
 
C

Chris Uppal

tom said:
[...] 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
 
R

Roedy Green

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
 
R

Roedy Green

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top