JDK 1.5 Features - OverView

There are 4 of them.
BY -- Joshua Bloch, Core Java Platform Group Architect, Sun Microsystems,

One is the Type Safety Enum feature. This is actually covered as a pattern in my book, 'How to do Typesafe Enums on top of Ordinary Classes.' But it is unfortunately somewhat verbose. So to do an Enum in a language like Pascal, or C++, or C#, you just say Enum Season {Winter, Spring, Summer, Fall}. Whereas to do a Typesafe Enum Pattern in Java, it was a large quantity of verbiage. Now you got a lot more power out of that because it was a real class you could put into collections, you could add methods to it, add fields to it, but unfortunately it was also somewhat more difficult to use. So this feature basically combines the power of this pattern that's described in my book with the expressivity and the ease of use of the standard Enum construct of the sort that you'll find in other languages. Most of those you'll find are merely glorified integers. They aren't type-safe, they aren't very powerful. So this one will be far more easy to use and more powerful.

There is a for each feature which is very simple. It is basically just a loop that let's you iterate over a collection or an array without explicit use of an iterator variable or an array index, when you don't need it.

Then there's autoboxing. As you know the Java type system is divided into two parts: the primitives and the objects. And in order to put a primitive into a collection you first have to box it. So an int goes into an Integer, a float goes into a Float, and so forth. And it makes for code that's a little bit messy, because you have to cast these things both going in and out of the collection. So with autoboxing you don't have to have those casts anymore.

The fourth feature is static import, which is a fairly simple feature. Currently, in order to access any static member of a class, whether it's a static field or a static method, you have to explicitly prefix it with the class name. So for instance math.pi or math.cos. And that is somewhat verbose and in particular it causes people to use an unsafe pattern. When people want to use a bunch of constants, instead of putting them in a class (and prefixing them with the class name), they put them in an interface and implement the interface to get all of its constants. But unfortunately that changes the public API of the class doing this trick because that class now implements this interface. And so what you want to is be able to do is use these static members without explicitly prefixing them. So what we're doing is we're adding an import statement much like the one that currently exists to import package members that allows you to import the static members of a class.
Instead Of,
double r = Math.cos(Math.PI * theta);
We User,
import static java.lang.Math.*;double r = cos(PI * theta);

Generics
The motivation is that currently, when you have Collection data types in Java, they are in fact Collections of Object and whenever you take anything out all you know is that it's an Object. And if you want to make it something more specific, you have to cast it explicitly. And if there's an error, so if you think there's a String in there and you cast what you've got out to a String, but in fact it's an Integer, you don't find out until runtime when your program blows up in the field. Now what Generics does for you is it takes that error and it moves it from runtime to compile time. So if you tried to take a String out of a collection of Integers, your program won't even compile any more. And furthermore, it eliminates the need for explicit casting. You declare the collection as being, say, a List of String rather than simply a List and then when you get an element, you get a String rather than getting Object and having to cast it to a String. And since you have no explicit casts, you have nothing that can fail. In fact, there are casts under the covers; the compiler generates them for you. But they don't fail; they are guaranteed to succeed.
more>>>