Language Features of J2SE 5.0 topics

Language Features of J2SE 5.0 topics
Author: Gao Yuxiang (Dawei)

 

1.1. Background
It has been more than three months since J2SE (TM) 5.0 was officially released. Just recently, Sun released the updated JDK 5.0 Update 1 just two weeks ago, removed some bugs in the first version.

 

The Java Community has been waiting for a long time to upgrade from version 1.4 to version 5.0. Everyone is very concerned about the changes worth noting in version 5.0. As a result, the relevant information of blog is full of information, I am also excited to add a series of articles in my blog. However, these blog articles, including my own, are usually extensive discussions, therefore, the editors of the second issue of CSDN Java electronic magazine plan to discuss this topic with relevant persons in depth.

 

As part of this issue of electronic publications, editors also invited me to discuss more systematically: what are the actual uses of the new language features introduced in J2SE (TM) 5.0, and why to introduce these new features. I am deeply honored with this. I am happy to share some of my Java experiences that may be considered as experience. I hope this article will help you understand J2SE (TM) 5.0.

1.2. Preparations
First, to understand the new language features of J2SE (TM) 5.0, You need to download the new JDK version. Here you can find the download link: http://java.sun.com/j2se/1.5.0/download.jsp. Of course, if you have already experienced manual configuration of the Java environment, I also recommend that you use an IDE that supports J2SE (TM) 5.0. We recommend that you use Eclipse SDK 3.1 M4 or NetBeans IDE 4.0. Both are open-source and free, and it is easy to find (Eclipse does not need to mention that NetBeans IDE 4.0 has a bundled version with JDK 5.0 Update 1 ).

 

To put it bluntly, Java versions seem to be a little lame since 1.2. Java (J2SE) is called Java 2, not Java 1.2 Since version 1.2, and is now more bizarre: Java (TM) 2 Platform Standard Edition 5.0 or J2SE (TM) 5.0, the internal version is 1.5.0. So is it 1, 2, or 5? Let's see what Sun's official website says:

 

It has been nine years since the birth of Java, and five years since the second generation of Java platform J2SE. In this context, changing the version number of the next version from 1.5 to 5.0 can better reflect the maturity, stability, scalability, and security of the new version J2SE.

 

Well, now we will face the following names, which refer to the same thing:

L Tiger

L Java (TM) 2 Platform Standard Edition 5.0

L J2SE (TM) 5.0

L Java version 1.5.0

L...

In this article, I will use the J2SE (TM) 5.0 name for convenience.

 

If you are interested in the code of each Java version, just like the "Tiger" here, you can refer to the following url: http://java.sun.com/j2se/codenames.html. To be disclosed, the code for the next Java version (6.0) is Mustang, and the Code for the next version (7.0) is doldolphin.

1.3. Overview
J2SE (TM) 5.0 introduced many radical language element changes, which reduce the coding burden of our developers more or less, most of them will be applied to the upcoming release of J2EE (TM) 5.0. Main new features include:

L generic

L enhanced for Loop

L automatic packing and automatic unpacking

L type-safe Enumeration

L Variable Length Parameter

L static Introduction

L metadata (annotation)

L C-style formatting output

 

In this case, generics, enumerations, and annotations may take up a large amount of space. I will give a brief introduction to the rest of them because their usage is straightforward or relatively simple, the rest is left for readers to think and explore.

1.4. Generic
The generic topic is quite large, so you can write a book on this topic. Discussions on whether Java requires generics and how to implement generics have been widely circulated in the Java Community. Finally, we saw it in J2SE (TM) 5.0. Maybe Java's support for generics is not ideal yet, but the addition of this feature is also good enough to surprise us.

 

In the following introduction, we will understand that although Java's generics look very similar to C ++'s generics, they are actually quite different, some details are also quite complex (at least many of them are contrary to our intuition ). It can be said that the introduction of generics greatly increases the complexity of the Java language and is especially a challenge for beginners. Next we will dig 1.1 points.

 

First, let's look at a simple example of using generic classes:

ArrayList <Integer> aList = new ArrayList <Integer> ();

AList. add (new Integer (1 ));

//...

Integer myInteger = aList. get (0 );

We can see that in this simple example, when defining aList, we specify that it is an ArrayList directly subject to Integer type. When we call aList. in get (0), we no longer need to explicitly convert the result to an Integer, and then assign the value to myInteger. This step is required in earlier Java versions. Maybe you are wondering, when using Collection, is some type conversion all of Java generics? Far more. In this example alone, there is at least one more benefit to generics, that is, the use of generic container classes becomes more robust: earlier, the get () of the Collection Interface () and the next () method of the Iterator interface can only return results of the Object type. We can forcibly convert this result to any Object subclass without any compilation errors, however, this is obviously likely to cause serious runtime errors, because the caller determines in the Code what type of objects are retrieved from a Collection, the caller may not be clear about the specific classes of objects to be put into the Collection; even if the caller knows the class of the object to be put in, it cannot be guaranteed that the object to be put into the Collection must be an instance of that class. Now with generics, the compiler can help us avoid similar problems as long as we specify which type of objects the Collection accepts when defining. We have seen too many ClassCastException in our actual work, right?

 

The usage of generics is also quite understandable from this example. When defining an ArrayList, we specify the object type accepted by this ArrayList using the value <> behind the class name. During compilation, this ArrayList will be processed as an object that only accepts the class or its subclass, so any statement that tries to add other types of objects will be rejected by the compiler.

 

So how is generic defined? Let's take a look at the following sample code: (In this example, the class name that will be used in practice by using the E-Token. Of course, you can also use another name. In the habit of using the upper-case E here, indicates the Collection element .)

Public class TestGenerics <E> {

Collection <E> col;

Public void dosomething (E elem ){

Col. add (elem );

//...

}

}

In the use of generics, there is an easy misunderstanding, that is, since Integer is derived from the Object, ArrayList <Integer> is of course a subclass of ArrayList <Object>. Is that true? When we think about it, we will find that this may cause problems: If we can convert ArrayList <Integer> to an ArrayList <Object>, so when we add an Object to the ArrayList after this transformation, can we add any type of Object (because the Object is the common parent class of all objects )? This clearly makes our ArrayList <Integer> lose its original purpose. Therefore, the Java compiler prohibits us from doing so. In this case, do ArrayList <Integer>, ArrayList <String>, and ArrayList <Double> have common parent classes? Yes, that is, ArrayList <?> .? It is called a wildcard here. To narrow down the scope of a wildcard, we usually need to write: ArrayList <? Extends SomeClass>. The written meaning is to define such a class ArrayList. For example, if SomeClass has SomeExtendedClass1 and SomeExtendedClass2, then the ArrayList <? Extends SomeClass> is the parent class of the following classes: ArrayList <SomeClass>, ArrayList <SomeExtendedClass1>, and ArrayList <SomeExtendedClass2>.

 

Next