Improvements to Program Execution Speed

Enhancements in JDK 6

Enhancements in JDK 5.0

The following are some of the enhancements made for improved
program execution speed in JDK 5.0.

Garbage collection ergonomics - Provides for the
automatic detection and choice of the client or server runtime
compiler, which enhances performance on server-class machines. See
"Server-Class Machine Detection" and "Garbage Collection
Ergonomics" at Java Virtual Machines
for more information.

StringBuilder class - The addition of a new class
StringBuilder
that works essentially as an unsynchronized StringBuffer for
performance enhancement. You should replace all StringBuffer uses
with StringBuilder unless you need the synchronization (which you
almost certainly don't). StringBuilder is almost always faster than
StringBuffer.

Java 2D technology - These Java 2D performance
enhancements have spin-off performance benefits in other areas of
functionality such as Swing/JFC. Examples include improved
acceleration for BufferedImage objects, support for
hardware-accelerated rendering using OpenGL, and improved
text-rendering performance. See New Java 2D Features for more
information.

Image I/O - Performance and memory usage improvements
have been made when reading and writing JPEG images. See "Improved
Performance" at Image I/O
Features.

Enhancements in JDK 1.4

The following are some of the enhancements made for improved
program execution speed in JDK 1.4.

Java 2D technology - These Java 2D performance
enhancements have spin-off performance benefits in other areas of
functionality such as Swing/JFC. One example of performance
improvement in JDK 1.4 is that remote X display on Solaris is
greatly improved. See New Java 2D
Features for more information on Java 2D enhancements,
including performance enhancements.

java.nio - The New I/O API provides for improved
performance in the areas of buffer management, scalable network and
file I/O, character-set support, and regular-expression matching.
The New I/O APIs supplement the I/O facilities in the
java.io package. For more information, see I/O APIs.

java.math - New static method probablePrime has been added to class
BigInteger for generating prime numbers. Previously, the
sole means of generating a prime BigInteger required the
caller to provide a 'certainty' (the log of the probability of
compositeness that the caller was willing to tolerate). However,
providing an unreasonable value for the certainty could lead to
poor performance (if the certainty was too high) or serious bugs
(if it was too low). The new prime-generation method provides an
efficient algorithm for generating primes using an automatically
determined, appropriate value for the certainty based on a draft
ANSI specification (X9-80).

Hotspot - The Java HotSpot virtual machine now uses
"full-speed debugging". In the previous version of HotSpot, when
debugging was enabled, the program executed using only the
interpreter. Now, the full performance advantage of HotSpot
Technology is available to programs running with debugging enabled.
The improved performance allows long running programs to be more
easily debugged. It also allows testing to proceed at full speed
and the launch of a debugger to occur on an exception.

Enhancements in JDK 1.3

The following are some of the changes made to improve the program
execution speed and general runtime performance in previous release
JDK 1.3. These enhancements have been carried forward into JDK
1.4.

Links to relevant bug reports on the Bug Database web site are
provided were applicable for further information.

Improved Performance for readUTF and writeUTF - The
implementations of the readUTF and writeUTF
methods of DataInputStream and DataInputStream
have been modified to improve performance. This is a fix for bug
number 4219771 on the
Bug Database web site.

Improved Performance of JScrollPane Painting - The
implementation of JScrollPane has been improved so that it does not
cause excessive painting and screen flashing when double buffering
is not used.

Improved JTable Performance - The performance of the
JTable's column-handling functionality has been improved.
Previously, the performance of the operations of adding columns or
recalculating column widths did not scale well as the number of
columns became large. The implementation has been changed to
improve scalability. This is a fix for bug number 4223642 on the
Bug Database web site.

Paint Coalescing - Painting performance has been
enhanced through the implementation of an improved paint coalescing
algorithm. Areas that require repainting are coalesced into a
single, non-rectangular repaint area as they are posted to the
event queue. This has the effect batching repaints, executing
multiple repaints simultaneously in a manner more efficient than in
previous releases.

Frame Resizing - Resizing of top-level frames has been
improved.

Internal Frame Blitting - By using
Graphics.copyArea calls, Swing's DefaultDesktopManager now
needs to redraw far less when frames are dragged.

Performance Enhancements in BigIntenger - Class
java.math.BigInteger has been reimplemented in pure Java
programming-language code. Previously, BigInteger's
implementation was based on the Plumb C library. The new
implementation performs all standard operations much faster than
the old implementation. The speed-up realized in the new
implemenation can be as much as 5x or more, depending on the
operation being performed.

Provision for Better-Performing Numeric Operations - Java SE now contains two classes which provide API for
performing general numeric operations.

java.lang.StrictMath
- Class java.lang.StrictMath is a renaming of class
java.lang.Math from previous versions of the Java
platform, but otherwise retains the previous specification of
Math. In particular, it is defined to return bit-for-bit
reproducible results in all implementations.

java.lang.Math - Class
java.lang.Math provides the same set of API as does class
StrictMath. However, unlike some of the numeric functions
of class StrictMath, all implementations of the equivalent
functions of class Math are not defined to return the
bit-for-bit same results, but can vary within specified
constraints. This relaxation permits better-performing
implementations where strict reproducibility is not required.