If you're a Java developer like me you ask two questions about every major J2SE release. What's new, and what's faster (or slower). Tiger includes a large number of well-publicized, high-profile features like generics, annotations, or the full new API for concurrent programming.

But the adoption of new features usually takes time, and until your J2EE product is updated to the new JRE; your corporate clients' admins let the new JREs pass; large teams get acquainted with new features, or complex systems are carefully redesigned to take advantage of such features. But even in these situations, it's always possible to move to the new J2SE as an optional deployment platform, just for the "free lunch" benefits of better performance or, as in J2SE 5.0, the JVM management features.

My approach here is to look at J2SE 5.0 as an improved runtime for existing apps. I'm sure that all the hard-working people at Sun and the many Tiger JSRs will be mad if developers don't hurry to all those cool new APIs and language features, but using J2SE 5.0 as "just a better runtime" is a good kick-in-the-door to push Tiger - remarkably inside more conservative shops where the rule of "if it ain't broken, don't fix it" drives advanced developers crazy. My personal answer is simple; if it's slow, then it is broken, and if the new JVM is faster, then the old is slow and therefore broken, and so are all my apps! But some facts are needed to substantiate this argument.

While J2SE updates always bring new optimizations and performance enhancements, it's also true that major new versions of any software (remarkably dot-zero ones) are often suspect of being "big bloated new version," and Java's no exception. Before proving that J2SE 5.0 is any faster than 1.4.2, we must first show that it's not slower, obeying the Hippocratic rule "First do no harm." So we'll approach each aspect of Java performance critically, first checking whether Tiger risks making anything worse, and only then looking at the possible gains.

New Features
New APIs are often bigger and more sophisticated than their predecessors (like Swing in Java 2 compared to the old AWT). This is what makes people cry, "Bloat!" (Until they can't live without the new API.) The good thing is that you only bother about the resource requirements of a new API, or about its performance, relative to previous alternatives. On the other hand, any performance advantages won't be collected before the new API is used. In short, existing apps shouldn't be affected, for better or worse, if deployed unchanged with the new runtime.

J2SE 5.0 adds some big new APIs, but they are useful to a narrow audience.

The new instrumentation, management, and debugging/profiler APIs are good for developing or monitoring scenarios. They have a performance impact, but only if active. If you're debugging, profiling, or monitoring a JVM instance via JMX or SNMP, you're obviously going to pay a price, but otherwise you shouldn't notice any difference because these features are available.

The new concurrency API, one of my Tiger favorites, can be used directly by advanced application developers, but most programmers writing business apps will only use this API indirectly once their middleware (like J2EE containers) are updated to exploit the new APIs. The good news is that when it happens, existing applications will benefit from more efficient concurrency (better performance and scalability) without any change.

J2SE 5.0 adds many small APIs, like those for formatting/scanning, but these won't have a significant impact in the footprint or other performance measures of most applications except perhaps in specialized apps that make heavy use of such APIs - e.g., some ETL tool that's rewritten to use java.util.Scanner to parse monster-sized text files.

Unlike the AWT Swing transition, there won't be a rush to port application code to a major new API from Tiger because there are no new APIs that are as broadly appealing. All the new Tiger features that should become "pop hits" are language-level features, even though some of them are supported by new improved APIs.

Generics have no performance (dis)advantages. That's part of the erasure deal; javac uses the generic types to do static validations, then discards these types, so the bytecodes produced are the same as usual (including typecasts). Classes and methods supporting generic parameters will grow a bit because javac will generate extra signature metadata in the .class files. But there's no impact at all on code that only uses generic types, either in the traditional way (e.g., declaring an ArrayList) or with the new generic syntax (e.g., declaring an ArrayList<String>).

Annotations tell a similar story. New metadata can be stored in the .class files, and be available through reflection. If you consider the amount of metadata that's already hacked into J2EE descriptiors, javadoc tags (especially with annotation-like tools such as Xdoclet), and the large number of new JSRs currently in development to define annotations for everything (servlets, EJB, Web Services, JDBC, and so on), it feels like a possible source of lots of space overhead. Fortunately, the Java annotation facility lets these overheads be controlled. The meta-annotation "Retention" ranges from SOURCE (zero overhead) to CLASS (it only makes classfiles bigger) and RUNTIME (annotations are available for reflection inspection, which consumes memory).

Other language enhancements like enhanced for, static import, autoboxing, and enums, have no direct performance impact good or bad. These features are mostly "syntax sugar." Indirectly, however, these features create some opportunities to change your performance. Autoboxing makes it all too easy to work with wrapped primitive values, e.g., to put integers inside collections. New code can use autoboxing carelessly in situations where one could work a bit harder (e.g., using primitive arrays instead of collections). On the other hand, when autoboxing replaces old code that used wrapper classes, the result should be more efficient. Autoboxing doesn't use wrappers' constructors (e.g., new Integer(99)), it uses new factory methods (Integer.valueOf(99)) that return cached objects for the most frequent values (like ints from -128 to +128). (You can also invoke these new methods manually.)

Updated Features
Updated APIs are a gray area. They may impact your performance even if you don't use the new or improved features. Even if you don't use any new methods, footprint and speed can be impacted when the improvements involve architectural changes to the APIs. There are some "suspects" in this category for J2SE 5.0.

The Unicode spec was updated in version 4.0, including characters that don't fit anymore in the 16-bit char type, requiring a pair of values for some extended characters. APIs for Strings, text formatting, and regex had to be updated for full compatibility with this new standard, breaking some assumptions that we thought cast in stone - e.g., String.length() still returns the number of chars in the string, but not necessarily the number of lexicographical units. This is now only assured by the new String.codePointCount() method. If you're a heavy user of core string classes (including the new StringBuilder), don't worry; the existing methods don't do anything to support Unicode 4.0; that's why there are new methods for this. But if you're a heavy user of higher-level text processing APIs, like java.util.regex.Matcher, their performance may have changed even if your app doesn't use the new Unicode characters, because the latter APIs will need to use the newer String methods anyway to be safe just in case the text contains Unicode 4.0 characters.