RE: To OPTIMIZE or not to OPTIMIZE...

> From: Adam Stotts
> 
> Survey poll: Of those of you who read this, have you optimized your
Java
> code with CRTJVAPGM, and if so, which option - *INTERPRET?  40? I am
> hearing conflicting opinions on this vital topic. Secondary question:
do
> you load classes from JAR files, or does your classpath only include
> Java class files?

There are two kinds of optimizations: static or compile time and dynamic
or runtime.  CRTJVAPGM is a static optimization, and the JIT compiler in
the JDK is a runtime optimization.  When JIT compilers first came out,
they weren't particularly efficient nor did they necessarily optimize
much better than a static optimization, so the static optimization of
CRTJVAPGM was the way to go.  Over the last several releases, the JIT
compiler has gotten much better, to the point where IBM will nearly
always suggest the JIT compiler rather than the static optimization of
CRTJVAPGM.

The thought process is that runtime optimizations can, in theory, take
into account not only the code of the classes to be optimized, but they
can also sort of intuit how the classes are being used, with the idea
being that the JIT compiler can actually optimize better than the static
compiler.  Now, this gets into a fuzzy area of programming that is
uncomfortably close to magic for me, but if it's true, add it to the
fact that the JIT compiler requires no potentially lengthy extra
preparation steps for delivery (and if you've ever done a CRTJVAPGM on
JTOpen, you know what I mean), and JIT seems to be a hands down winner.

It would be nice to hear from Blair Wyman or someone else on the
compiler team as to whether my lay-person's explanation of optimization
is close enough for rock and roll.

As to classes vs. JAR files, in my current project 100% of my classes
are in JAR files.  This includes servlets and beans.  I can't actually
see a reason to not use JAR files.  I suppose there might be some
performance issues, but since I'm counting on an optimizing compiler,
I'm much less likely to worry about a little first-time instantiation
overhead.  Now there is a real issue with hot swapping JAR files in a
running application server, but I haven't run into that issue; maybe
someone else can address it better than I can.

Joe