yeah, i am using third party jars as well, good one tom :)
>>> 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
>[...] 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
>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.