Each new release of the Java platform potentially changes three things:

Not every new platform release changes all three—in particular, changes to the class format occur rarely because of the major impact such changes can have.

The compiler that comes with the Java Development Kit (JDK) tracks changes to the language and virtual machine through the use of “source” and “target” options that can be passed to it. By supplying an appropriate source and target pair you can compile code that will run on current or older versions of the virtual machine—assuming the code is compatible with the source version of the language chosen.

The different source versions and their approximate meaning are as follows:

Similarly, the target versions are

Because some language changes require new library classes, a change in the source version may imply a minimum target value. For example, a source of 1.4 requires a target of 1.4 because an earlier version of the virtual machine won't have the classes or methods that support assertions. Not surprisingly, a source of 1.5 requires a target of 1.5 as well. Naturally, source and target versions that came into existence after a given compiler was released are not supported.

Each target version causes a change in the class file version number that is encoded in the compiled classes. Each virtual machine knows what class versions it supports and will generally refuse to load any class files that have a higher version number. This means, for example, that you can prevent a class from being loaded on an older virtual machine even if there is no missing functionality in the version.

The default settings for the compiler in the 5.0 release are source 1.5 and target 1.5 to enable all the latest features of the language. If you compile code to run on previous versions (which doesn't use the new features of course) you'll need to explicitly set the target to a suitable earlier version.

Adding new keywords to the language runs the risk of breaking existing code, especially if the word is an identifier as common as “assert” or “enum.”^[1] The choice to add a new keyword creates some interesting and important compatibility issues. Taking assertions as an example, you can choose whether or not assert is recognized in your code by selecting a source version of 1.4 or higher. This allows you to keep your old use of “assert” in one class, while using the language assertions in another—provided the different uses are independent. When asserts were introduced in the 1.4 release, the default source version was left at 1.3 so by default nothing changed and you had to explicitly tell the compiler when you were ready to use the new language feature. In the 5.0 release the presumption is that everyone will want to use at least some of the new features, so they are enabled by default—if you don't want them you must either specify the appropriate source version or use an older version of the compiler.

These side-by-side dialects can create problems. With only one dialect you could use the same compiler, and the same compiler options, on all your source code. With two or more dialects you might have some source files that require assert or enum and others that reject it. You will have to compile your source carefully to handle such a situation. At this point, there are three dialects: with assert and enum (5.0), with assert but not enum (1.4), and without either (1.3 and earlier).

The obvious solution is to use a single dialect for all your source. But you will not always have that kind of control. If you are using source produced by another group they may have moved on while you cannot, or vice versa.

This is deeper than you might hope. Suppose you have two source files, Newer.java which uses the assert keyword and Older.java which uses “assert” as a method name. If the newer class depends on the older and neither has yet been compiled, compiling Newer.java will attempt to compile Older.java as well. With only one dialect this is a feature. But with the incompatible dialects you will be unable to compile Newer.java until you have already compiled Older.java under the non-assert dialect. This complicates your build process because the order in which you compile things has now become significant.

Of course, the ultimate problem is if Newer.java and Older.java depend on each other. Now you have a loop you cannot solve without modifying one source file. Presumably you would upgrade Older.java to use the new dialect, but if you cannot do so you will have to regress Newer.java to the older dialect.

Woe betide if you can modify neither.

The generic type system was added to the Java programming language for the 5.0 release. The design was strongly constrained by the need to maintain compatibility between independently developed code modules that may or may not include the use of generics. The key design decision was that generic types could not be reified at runtime. Rather, for each generic type declaration there would be a single type that was defined in terms of the erasure of its type variables. As we discussed in Chapter 11, in simple terms the type is defined such that each type variable is replaced by its bound—commonly Object. The reasoning behind this decision is beyond the scope of this book, but to quote JLS 4.7 (The Java^™ Language Specification, Third Edition, Section 4.7):

Note that in the future, this design decision might be changed.

interface PassThrough<T> {
    T passThrough(T t);
}

class PassThroughString implements PassThrough<String> {
    public String passThrough(String t) {
        return t;
    }
}

public static void main(String[] args) {
    PassThrough s = new PassThroughString();
    s.passThrough(args);
}

public Object passThrough(Object o) {
    return passThrough((String)o);
}

public static Object newInstance(Class<?> type, int length)

public static <T> T[] newInstance(Class<T> type, int length)