Ian Darwin’s Java History

You want a convenient means of accessing all the elements of an array or collection. The Java 5 foreach loop syntax is as follows:

For example:

This form of for is pronounced as "for each" and is referred to that way in the documentation and the compiler messages; the colon (:) is pronounced as "in" so that the statement is read as "foreach String s in myListOfStrings." The String named s will be given each value from myListOfStrings for one pass through the loop. How is myListOfStrings declared? The foreach construction can be used on Java arrays, on Collection classes, and on anything that implements the Iterable interface. The compiler turns it into an iteration, typically using an Iterator object where Collection classes are involved. ForeachDemo.java shows using foreach to iterate through an array and a List.

In modern Java, the foreach loop is used more commonly than the older for loop. The main times when the older style would be used are:

Enumerations implement the Typesafe Enumeration Pattern described in Josh Bloch’s book Effective Java. Bloch worked at Sun to implement this language feature, among others. The basic idea is that where you have a small, rarely changing set of values, it makes sense to list them and have them known at compile time. For example, the colors at a stoplight are red, amber, and green; we might code this as in Color.java, at a bare minimum.

Enums are covered in [javacook-CHP-8-SECT-5].

Java Annotations are metadata-like "sticky notes" that you can attach to various places in your Java code to provide extra information beyond normal Java syntax and semantics. Some (such as java.lang.Override) are only used at compile time; others—​the majority—​are consulted at runtime. They are described, with examples, in [javacook-reflection-annotations].

One of the most notable additions to Java 5 is "generic types," such as collections, that are defined to hold objects of a certain type rather than just Object (obviating the downcast otherwise needed each time you get an object back from a collection). For example, with a List of Strings, prior to 1.5 you might have written the code in ListsOldAndNew.java.

In Java 5, you would be more likely to write this as:

This mechanism is called "generics" because it allows you to write generic classes, the arguments and return types of methods of which are specified when the class is instantiated.

Although the original definition of the List interface and the ArrayList class had methods dealing in java.lang.Object, in 1.5 these types have been changed to a Generic type or "type parameter" so that you can declare and instantiate them with any object type (String, Customer, Integer), and get the benefits of stronger type checking and elimination of downcasts.

Not just these types, but all of the Collections API and most of the other parts of the standard Java API in 1.5 have been updated to be generic types. If you write your own multipurpose classes, you can fairly easily change them to be generics in the same fashion.

The notation <type> is used to specify the particular type with which the class is to be instantiated. Java developers had better get comfortable with this notation, because it is used extensively in the 1.5 javadoc!

These additions related to data structuring are all covered in [javacook-structure]. Also see Java Generics and Collections.

Java 5 introduced method declarations with variable-length argument lists, commonly called "varargs." This allows you to write a method that can be called with any number of arguments of the given type. For example, a method mySum to be called with a variable number of int arguments can be written as:

Note that there can only be one variable-length argument list in the parameter list of a method, and that it must be last; there can be other arguments before it, but not after.

Any of the following would be a valid call to this method:

That last one may be a bit surprising. When you think about it, the "…​" in a method declaration is a kind of syntactic sugar for "array of," so you can pass an explicit array. This does not mean that arrays and ... are interchangeable; if you declare the method parameter as, say, int[] args, then you will be required to pass an array, not use a variable-length argument list.

The objects can be of any type; see the file lang/VarArgsDemo.java for examples of other types, and argument lists with other arguments before the varargs in the method declaration.

Java was the first mainstream language with explicit support for multithreading. It has always been possible to write Java applications that run multiple sections of code more or less concurrently. In fact, even the simplest Java application creates at least one thread—Java’s memory allocation garbage collection runs in a background thread, started by the Java runtime before you can say "Hello World."

However, the code required has sometimes been slightly convoluted. In Java 1.5, the API has been significantly expanded to provide a series of utility classes that make it much easier to support multithreaded applications. Even such complex operations as various types of locking, and creation of thread pools, have been addressed. This work is an outgrowth of an open source library developed by Doug Lea, author of the book Concurrent Programming in Java (Addison-Wesley) and a computer science professor at State University of New York in Oswego, New York. This code was contributed to the Java Community Process where it has been extensively worked over by a multitasking committee of multithreading experts. The package java.util.concurrent and its subpackages contain all of the new classes, and there are quite a few of them.

One of the key differences from traditional Java synchronization is that the new classes really are concurrent. In other words, while a synchronized class such as Vector or Hashtable uses the object’s monitor lock to block all but a single thread from running any synchronized method at a time, the new concurrent classes will allow multiple threads to access them at the same time, yet still provide "thread-safe" access. For example, the new ConcurrentHashMap class allows an unlimited number of concurrent reading threads and a (settable) maximum number of writes. This will generally lead to much better scalability and faster performance, both of which become important when designing enterprise-scale application services. What’s also nice about the ConcurrentHashMap is that, because it still implements the Map interface from java.util, it is a drop-in replacement for the older synchronized Hashtable class (in most cases, but do refer to the documentation for some edge cases that need consideration). Using it where suitable is as simple as adding an import and changing:

to

Of course, because you read the section on Generics (see Java 5 generic types), you’ll know that you probably want to use it in a typesafe way, so if your Map were hashing from a String to a CustomerAddress object, you’d actually write:

I did say you have to get used to that <type> notation. Note that in 1.5, the Map interface is now declared as Map<K, V> (for Keys and Values); the iteration methods are declared in the interface as Enumeration<K> keys() and Collection<V> values(). So in this example you would get Enumeration<String> keys() and Collection<CustomerAddress> values from the "keys" and "values" methods, respectively.

Since you give the type for the keys and values when you instantiate a class implementing Map, you get back the iterators with the correct types built in, meaning no downcast needed when you extract the elements.

In the early days of Java, it was common for people to try to bring the C-language printf functionality to Java. Most of these attempts worked only for certain cases, and were not really object-oriented approaches. After much prodding from developers and much internal debate, Sun relented and included printf functionality into Java 5.

The functionality is contained in the new java.util.Formatter class (not to be confused with the existing DateFormat, NumberFormat, etc., classes) and is also available in convenience routines in System.out (actually, in the PrintStream and PrintWriter classes). The format codes are more comprehensive than the original C printf, but the basic idea is the same: you pass a format string and one or more objects to be formatted according to the format string. For example, you might write:

The % is the lead-in to the format code, and the 6.4f is (as it was in printf and in Fortran before that) the code to print a floating-point value with a field-width of six characters and four digits after the decimal place. So the program prints:

There is much more to this, with support for date formatting, localization, and more. See the documentation for java.util.Formatter for details.

There is also scanf-like functionality, in the [javacook-io-SECT-5]. This does not use % format codes, but uses a variety of next() methods, such as next(String), next(Pattern), nextInteger, nextDouble, and so on, plus all of the corresponding hasNext() methods. See the documentation for java.util.Scanner. printf, and the scanning utilities are covered in [javacook-io-SECT-5.3].

Some of the Java 5 material in this section originally appeared in an article I wrote on O’Reilly Web back in the day.

You can now list multiple exception types in one catch:

In previous versions of Java you’d have needed three catch clauses with a lot of copy-and-paste, error-prone error handling, or, have something like catch (Exception e), which might be more than you want to catch.

Another great simplification for proper error handling! You can now create resources (I/O Streams/Writers, JDBC Connections, …​) as the argument of a try statement and have them closed automatically. The resource must implement the (new for this purpose) AutoCloseable interface. Many standard classes have been modified to implement AutoCloseable to support this.

Java 5 introduced Generic Types, as described in Java 5 generic types. For example, to create a List of Strings without any warning messages, you might write:

Java 7 brings "Type Inference" for Generic Types, also called the "diamond operator". Instead of having to repeat the type parameter from the declaration in the definition, omit it and just put <>. The preceding list of strings can be rewritten as:

This long-awaited feature lets you replace a series of if statements using string comparisons, by a single switch statement; i.e., you can now use Strings as case labels:

Obviously the strings have to be compile-time constants, either string literals or strings marked final. In fact, in real code, you would probably want to define final String variables for the cases. This should lead you to wonder why you’re not using a Java 5 Enum (see Java 5 enums). The String Switch has a place where long strings are in use, but it needs care for issues like case sensitivity (convert to lowercase first, see [javacook-strings-SECT-9.1]).