Support for generics has been a long requested enhancement. It eliminates the need to use casts to change the type of a referenced object. Previously, Java collections were typically created to hold objects of type Object, and the programmer had to convert an Object reference to a more useful class before using the object.
Generics provide compile-time type checking. They also eliminate parentheses associated with casts and temporary variables often used to manage conversion. This reduces source-code complexity.
In addition, generics provide some but not all of the features found in C++ templates. As a result, generics can be implemented with no change in code size, because the underlying Java bytecodes are essentially the same as using casts in older versions of Java.
Generics are very useful in Java collections, and collections are often used in applications. It’s not surprising that a new looping construct was added to simplify the use of collections and the Iterator interface. The typical Java for statement requires an iterator variable to appear three times in the statement. That is two too many. The new syntax is simple and safe, and it’s used for arrays as well.
Java enumerations eliminate the need to use the int Enum pattern, where enumerated values are simply a set of unrelated integer constants. The pattern approach requires the constants to be prefixed by the class name, and it’s not type safe.
The new Java enum support provides a type-safe implementation that’s significantly more sophisticated than most enumeration support found in other programming languages. The new implementation is more akin to a specialized class definition. The simplest case is just a list of constants, but Java enum definitions can add methods and fields. Enum values can be employed in Java switch statements.
C and C++ have long had variablelength argument lists. Conversely, Java’s only recourse has been fixed parameter lists. That’s resulted in painful repetition of method calls to do tasks such as outputting a variable size list of variables. An equally annoying approach is to define an array and assign the variables to entries in the array. The array is then passed to the function that now must handle the array parameter.
The Java variable-length arguments follow the array approach but completely hide the array allocation and initialization. Unlike C, the type of array is specified with the Java syntax. The approach requires minimal change to the Java syntax and no change to the underlying Java virtual machine— everything is handled within the compiler. Best of all, the actual argument array handling isn’t special. Rather, it’s just a generic Java array.
Unfortunately, a Java int isn’t a Java Integer object. It’s possible to have a variable-length argument of ints. However, if the list of arguments is a class type, then a problem may arise. To solve this and similar problems, the new standard includes support for autoboxing. Autoboxing essentially performs the conversion between a primitive data type like int and a class like Integer.
The static imports feature differs from the prior enhancements because it’s designed to simplify syntax more than semantics. Prior to Java 5.0, public constants and class methods could only be accessed by prefixing them with the class name. This led to expressions like Math.abs(Math.cos(45)) instead of the more succinct abs(cos(45)).
The reason for this, at times, extraneous text was to allow classes with conflicting names to be used simultaneously No problem exists if the class name is always specified, but many times there’s no conflict at all. Simply adding the static keyword to the Java import statement essentially brings the names associated with statically imported classes into the namespace of the program. This enables the feature to be applied to any class.
Java doesn’t have macros, which could be considered good or bad. There are a number of instances that require similar functionality. For example, many application programming interfaces (APIs) need additional files to be maintained.
Java’s new metadata allows the specifications to be placed in the source code. Therefore, other tools can process the metadata-enabled source code to generate these files. It can also generate Java source code, essentially providing macro-like capability but placing the conversion process into another application. Metadata isn’t restricted to tools that add boilerplate. It can be used to enhance runtime tools like debuggers and even test and qualityassurance applications.
All of the changes made to the Java language have been brewing for quite some time, so there’s been plenty of discussion concerning its advantages and tradeoffs. But competition with other programming languages like C, C++, and C# simply forced the hand of Java designers. The results are gratifying and well worth the two-year wait since Java 1.4’s introduction.
Exploiting the new features requires a complete overhaul of the underlying language and runtime tools. A new compiler and Java virtual machine are needed to use all of the features. Java 5.0 SE(Standard Edition) is now out, and most Java implementations will soon follow.
Using these features in an embedded environment will take time. Luckily, though, the language changes will be relatively easy to incorporate. That’s because the language enhancements are relatively clean, easy to understand, and applicable to almost every Java programmer.
There’s more to come. In fact, these enhancements are just the tip of the iceberg when it comes to the Java 5.0.
Sun Microsystems www.sun.com