JAVA 1.5 features | update Java 7 features

This Blog covers these topics: Java 1.5 interview questions / Java 1.5 updates / Java 1.7 updates. These are main changes in java 1.5 [ Tiger Release ] and these details are taken from SUN publication on jdk 1.5.

JAVA 1.5 New Features:
In Summary:
1) Generics
2) Enhanced For Loop
3) Autoboxing / Unboxing
4) Enums
5) Varags
6) Static Import
7) Metadata / Annotations
8) Garbage Collectors
9) Java Concurrent package

Worth reading java 1.7 changes to confirm that you are up-to-date for java changes.

Java 1.7 features  

Details of each change in java 1.5-

Generics

This long-awaited enhancement to the type system allows a type or method to operate on objects of various types while providing compile-time type safety. It adds compile-time type safety to the Collections Framework and eliminates the drudgery of casting. Refer to JSR 14.

      Generics provides a way for you to communicate the type of a collection to the compiler, so that it can be checked. Once the compiler knows the element type of the collection, the compiler can check that you have used the collection consistently and can insert the correct casts on values being taken out of the collection.

Example

static void expurgate(Collection; c) {

    for (Iterator; i = c.iterator(); i.hasNext(); )

      if (i.next().length() == 4)

        i.remove();

}

  The java.util.Collections class has been outfitted with wrapper classes that provide guaranteed run-time type safety. They are similar in structure to the synchronized and unmodifiable wrappers. These “checked collection wrappers” are very useful for debugging. Suppose you have a set of strings, s, into which some legacy code is mysteriously inserting an integer. Without the wrapper, you will not find out about the problem until you read the problem element from the set, and an automatically generated cast to String fails. At this point, it is too late to determine the source of the problem. If, however, you replace the declaration:

    Set s = new HashSet();

Enhanced for Loop

This new language construct eliminates the drudgery and error-proneness of iterators and index variables when iterating over collections and arrays. Refer to JSR 201 .

   Iterating over a collection is uglier than it needs to be. Consider the following method, which takes a collection of timer tasks and cancels them:

void cancelAll(Collection; c) {

    for (Iterator; i = c.iterator(); i.hasNext(); )

        i.next().cancel();

       }

   The iterator is just clutter. Furthermore, it is an opportunity for error. The iterator variable occurs three times in each loop: that is two chances to get it wrong. The for-each construct gets rid of the clutter and the opportunity for error. Here is how the example looks with the for-each construct:

void cancelAll(Collection ; c) {
    for (TimerTask t : c)
        t.cancel();

  }
  When you see the colon (:) read it as “in.” The loop above reads as “for each TimerTask t in c.” As you can see, the for-each construct combines beautifully with generics. It preserves all of the type safety, while removing the remaining clutter. Because you don't have to declare the iterator, you don't have to provide a generic declaration for it. (The compiler does this for you behind your back, but you need not concern yourself with it.

Autoboxing/Unboxing

This facility eliminates the drudgery of manual conversion between primitive types (such as int) and wrapper types (such as Integer). Refer to JSR 201 .

   As any Java programmer knows, you can’t put an int (or other primitive value) into a collection. Collections can only hold object references, so you have to box primitive values into the appropriate wrapper class (which is Integer in the case of int). When you take the object out of the collection, you get the Integer that you put in; if you need an int, you must unbox the Integer using the intValue method. All of this boxing and unboxing is a pain, and clutters up your code. The autoboxing and unboxing feature automates the process, eliminating the pain and the clutter.

   The following example illustrates autoboxing and unboxing, along with generics and the for-each loop. In a mere ten lines of code, it computes and prints an alphabetized frequency table of the words appearing on the command line.

 import java.util.*;

// Prints a frequency table of the words on the command line

public class Frequency {

   public static void main(String[] args) {

      Map m = new TreeMap();

      for (String word : args) {

          Integer freq = m.get(word);

          m.put(word, (freq == null ? 1 : freq + 1));

      }

      System.out.println(m);

  }

}

java Frequency if it is to be it is up to me to do the watusi

{be=1, do=1, if=1, is=2, it=2, me=1, the=1, to=3, up=1, watusi=1}

Typesafe Enums
   This flexible object-oriented enumerated type facility allows you to create enumerated types with arbitrary methods and fields. It provides all the benefits of the Typesafe Enum pattern ("Effective Java," Item 21) without the verbosity and the error-proneness. Refer to JSR 201.

In prior releases, the standard way to represent an enumerated type was the int Enum pattern:

// int Enum Pattern - has severe problems!

public static final int SEASON_WINTER = 0;

public static final int SEASON_SPRING = 1;

public static final int SEASON_SUMMER = 2;

public static final int SEASON_FALL   = 3;

This pattern has many problems, such as:

• Not typesafe - Since a season is just an int you can pass in any other int value where a season is required, or add two seasons together (which makes no sense).

• No namespace - You must prefix constants of an int enum with a string (in this case SEASON_) to avoid collisions with other int enum types.

• Brittleness - Because int enums are compile-time constants, they are compiled into clients that use them. If a new constant is added between two existing constants or the order is changed, clients must be recompiled. If they are not, they will still run, but their behavior will be undefined.

• Printed values are uninformative - Because they are just ints, if you print one out all      you get is a number, which tells you nothing about what it represents, or even what type it is.

     It is possible to get around these problems by using the Typesafe Enum pattern (see Effective Java Item 21), but this pattern has its own problems: It is quite verbose, hence error prone, and its enum constants cannot be used in switch statements.

    In 5.0, the Java™ programming language gets linguistic support for enumerated types. In their simplest form, these enums look just like their C, C++, and C# counterparts:

      enum Season { WINTER, SPRING, SUMMER, FALL }

 All enums implicitly extend java.lang.Enum. Since Java does not support multiple inheritance, an enum cannot extend anything else. The constructor for an enum type must be package-private or private access. It automatically creates the constants that are defined at the beginning of the enum body. You cannot invoke an enum constructor yourself.

Varargs

  This facility eliminates the need for manually boxing up argument lists into an array when invoking methods that accept variable-length argument lists. Refer to JSR 201.

   In past releases, a method that took an arbitrary number of values required you to create an array and put the values into the array prior to invoking the method. For example, here is how one used the MessageFormat class to format a message:

Object[] arguments = {

    new Integer(7),

    new Date(),

    "a disturbance in the Force"

};

String result = MessageFormat.format(

    "At {1,time} on {1,date}, there was {2} on planet "

     + "{0,number,integer}.", arguments);

   It is still true that multiple arguments must be passed in an array, but the varargs feature automates and hides the process. Furthermore, it is upward compatible with preexisting APIs. So, for example, the MessageFormat.format method now has this declaration:

    public static String format(String pattern, Object... arguments);

Static Import
  This facility lets you avoid qualifying static members with class names without the shortcomings of the "Constant Interface antipattern." Refer to JSR 201.

  In order to access static members, it is necessary to qualify references with the class they came from. For example, one must say:

         double r = Math.cos(Math.PI * theta);

  In order to get around this, people sometimes put static members into an interface and inherit from that interface. This is a bad idea. In fact, it's such a bad idea that there's a name for it: the Constant Interface Antipattern (see Effective Java Item 17). The problem is that a class's use of the static members of another class is a mere implementation detail. When a class implements an interface, it becomes part of the class's public API. Implementation details should not leak into public APIs.

          The static import construct allows unqualified access to static members without inheriting from the type containing the static members. Instead, the program imports the members, either individually:

import static java.lang.Math.PI;

or en masse:

import static java.lang.Math.*;

Once the static members have been imported, they may be used without qualification:

double r = cos(PI * theta);

Metadata (Annotations)
Annotations provide data about a program that is not part of the program itself. They have no direct effect on the operation of the code they annotate.

Annotations have a number of uses, among them:

• Information for the compiler — Annotations can be used by the compiler to detect errors or suppress warnings.
• Compiler-time and deployment-time processing — Software tools can process annotation information to generate code, XML files, and so forth.
• Runtime processing — Some annotations are available to be examined at runtime.

Annotations can be applied to a program's declarations of classes, fields, methods, and other program elements.

The annotation appears first, often (by convention) on its own line, and may include elements with named or unnamed values:

@Author(

   name = "Benjamin Franklin",

   date = "3/27/2003"

)

class MyClass() { }

or

@SuppressWarnings(value = "unchecked")

void myMethod() { }

There are three annotation types that are predefined by the language specification itself: @Deprecated, @Override, and @SuppressWarnings[example - @SuppressWarnings("deprecation")].

Annotation Processing

The more advanced uses of annotations include writing an annotation processor that can read a Java program and take actions based on its annotations. It might, for example, generate auxiliary source code, relieving the programmer of having to create boilerplate code that always follows predictable patterns. To facilitate this task, release 5.0 of the JDK includes an annotation processing tool, called apt. In release 6 of the JDK, the functionality of apt is a standard part of the Java compiler.

To make annotation information available at runtime, the annotation type itself must be annotated with @Retention(RetentionPolicy.RUNTIME), as follows:

import java.lang.annotation.*; 

@Retention(RetentionPolicy.RUNTIME)

@interface AnnotationForRuntime {

   // Elements that give information

   // for runtime processing

}

Virtual Machine

Class Data Sharing

  The class data sharing feature is aimed at reducing application startup time and footprint. The installation process loads a set of classes from the system jar file into a private, internal representation, then dumps that representation to a "shared archive" file. During subsequent JVM invocations, the shared archive is memory-mapped in, saving the cost of loading those classes and allowing much of the JVM's metadata for these classes to be shared among multiple JVM processes. For more information, click the above link.

   Class data sharing (CDS) is a new feature in J2SE 5.0 intended to reduce the startup time for Java programming language applications, in particular smaller applications, as well as reduce footprint. When the JRE is installed on 32-bit platforms using the Sun provided installer, the installer loads a set of classes from the system jar file into a private internal representation, and dumps that representation to a file, called a "shared archive". Class data sharing is not supported in Microsoft Windows 95/98/ME. If the Sun JRE installer is not being used, this can be done manually, as explained below. During subsequent JVM invocations, the shared archive is memory-mapped in, saving the cost of loading those classes and allowing much of the JVM's metadata for these classes to be shared among multiple JVM processes.

   In J2SE 5.0, class data sharing is supported only with the Java HotSpot Client VM, and only with the  serial garbage collector.

The primary motivation for including CDS in the 5.0 release is the decrease in startup time it provides. CDS produces better results for smaller applications because it eliminates a fixed cost: that of loading certain core classes. The smaller the application relative to the number of core classes it uses, the larger the saved fraction of startup time.

 The footprint cost of new JVM instances has been reduced in two ways. First, a portion of the shared archive, currently between five and six megabytes, is mapped read-only and therefore shared among multiple JVM processes. Previously this data was replicated in each JVM instance. Second, since the shared archive contains class data in the form in which the Java Hotspot VM uses it, the memory which would otherwise be required to access the original class information in rt.jar is not needed. These savings allow more applications to be run concurrently on the same machine. On Microsoft Windows, the footprint of a process, as measured by various tools, may appear to increase, because a larger number of pages are being mapped in to the process' address space. This is offset by the reduction in the amount of memory (inside Microsoft Windows) which is needed to hold portions on rt.jar. Reducing footprint remains a high priority.

Garbage Collector Ergonomics

The parallel collector has been enhanced to monitor and adapt to the memory needs of the application. You can specify performance goals for applications and the JVM will tune the size of the Java heap to meet those performance goals with the smallest application footprint consistent with those goals. The goal of this adaptive policy is to eliminate the need to tune command-line options to achieve the best performance. For a synopsis of garbage collection features, click the above link.

The following changes take effect with J2SE 5.0.

on server-class machines running the server VM, the garbage collector (GC) has changed from the previous serial collector (-XX:+UseSerialGC) to a parallel collector (-XX:+UseParallelGC). You can override this default by using the -XX:+UseSerialGC command-line option to the java command.

1. On server-class machines running either VM (client or server) with the parallel garbage collector (-XX:+UseParallelGC) the initial heap size and maximum heap size have changed as follows.

initial heap size:

Larger of 1/64th of the machine's physical memory on the machine or some reasonable minimum. Before J2SE 5.0, the default initial heap size was a reasonable minimum, which varies by platform. You can override this default using the -Xms command-line option.

maximum heap size:

Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0, the default maximum heap size was 64MB. You can override this default using the -Xmx command-line option.

Server-Class Machine Detection

At application startup, the launcher can attempt to detect whether the application is running on a "server-class" machine.

Starting with J2SE 5.0, when an application starts up, the launcher can attempt to detect whether the application is running on a "server-class" machine and, if so, use the Java HotSpot Server Virtual Machine (server VM) instead of the Java HotSpot Client Virtual Machine (client VM). The aim is to improve performance even if no one configures the VM to reflect the application it's running. In general, the server VM starts up more slowly than the client VM, but over time runs more quickly.

Note: For J2SE 5.0, the definition of a server-class machine is one with at least 2 CPUs and at least 2GB of physical memory.

In J2SE 5.0, server-class detection occurs if neither -server nor -client is specified when launching the application on an i586 or Sparc 32-bit machine running Solaris or Linux. As the following table shows, the i586 Microsoft Windows platform is not subject to the server-class test (i.e., is never treated as a server-class machine by default) and uses the client VM by default. The remaining Sun-supported platforms use only the server VM.

Lang and Util Packages

J2SE Development Kit 5.0 has several enhancments in the java.lang.* and java.util.* packages, including:

·         ProcessBuilder - The new ProcessBuilder class provides a more convenient way to invoke subprocesses than does Runtime.exec. In particular, ProcessBuilder makes it easy to start a subprocess with a modified process environment (that is, one based on the parent's process environment, but with a few changes).

·         Formatter - An interpreter for printf-style format strings, the Formatter class provides support for layout justification and alignment, common formats for numeric, string, and date/time data, and locale-specific output. Common Java types such as byte, java.math.BigDecimal , and java.util.Calendar are supported. Limited formatting customization for arbitrary user types is provided through the java.util.Formattable interface.

·         Scanner - The java.util.Scanner class can be used to convert text into primitives or Strings. Since it is based on the java.util.regex package, it also offers a way to conduct regular expression based searches on streams, file data, strings, or implementors of the Readable interface.

·         Concurrency Utilities The java.util.concurrent, java.util.concurrent.atomic, and java.util.concurrent.locks packages provide a extensible framework of high-performance, scalable, thread-safe building blocks for developing concurrent classes and applications, including thread pools, thread-safe collections, semaphores, a task scheduling framework, task synchronization utilities, atomic variables, and locks. Additionally, these packages provide low-level primitives for advanced concurrent programming which take advantage of concurrency support provided by the processor, enabling you to implement high-performance, highly scalable concurrent algorithms in Java to a degree not previously possible without using native code. For more information, refer to JSR 166 .

·         Collections Framework Enhancements - There are many enhancements to the Collections framework.

·         Instrumentation - The new java.lang.instrument package provides services that allow Java programming agents to instrument programs running on the Java virtual machine by modifying methods' bytecodes at runtime.

·         Threads - The java.lang.Thread class has the following enhancements:

o    Thread priority handling has changed.

o    Thread.State enum class and the new getState() API are provided for querying the execution state of a thread.

o    The new thread dump API - the getStackTrace and getAllStackTraces methods in the Thread class - provides a programmatic way to obtain the stack trace of a thread or all threads.

o    The uncaughtExceptionHandler mechanism, previously available only through the ThreadGroup class, is now available directly through the Thread class.

o    A new form of the sleep() method is provided which allows for sleep times smaller than one millisecond.

Scanner

The java.util.Scanner class can be used to convert text into primitives or Strings. Since it is based on the java.util.regex package, it also offers a way to conduct regular expression based searches on streams, file data, strings, or implementors of the Readable interface. A simple text scanner which can parse primitive types and strings using regular expressions.

A Scanner breaks its input into tokens using a delimiter pattern, which by default matches whitespace. The resulting tokens may then be converted into values of different types using the various next methods.  For example, this code allows a user to read a number from System.in:

     Scanner sc = new Scanner(System.in);

     int i = sc.nextInt();

Concurrency Utilities

The java.util.concurrent, java.util.concurrent.atomic, and java.util.concurrent.locks packages provide a powerful, extensible framework of high-performance, scalable, thread-safe building blocks for developing concurrent classes and applications, including thread pools, thread-safe collections, semaphores, a task scheduling framework, task synchronization utilities, atomic variables, and locks. The addition of these packages to the core class library frees the programmer from the need to craft these utilities by hand, in much the same manner that the Collections Framework did for data structures. Additionally, these packages provide low-level primitives for advanced concurrent programming which take advantage of concurrency support provided by the processor, enabling programmers to implement high-performance, highly scalable concurrent algorithms in the Java language to a degree not previously possible without resorting to native code. Refer to JSR 166 .

Threads

The java.lang.Thread class has the following enhancements:

      .Thread priority handling has changed; see the above link for details.

      ·  Thread.State enum class and the new getState() API are provided for querying the execution state of a thread.

   · The new thread dump API - the getStackTrace and getAllStackTraces methods in the Thread class - provides a programmatic way to obtain the stack trace of a thread or all threads.

      ·  The uncaughtExceptionHandler mechanism, previously available only through the ThreadGroup class, is now available directly through the Thread class.

·         A new form of the sleep() method is provided which allows for sleep times smaller than one millisecond.

The Concurrency Utilities includes:

• Task Scheduling Framework - The Executor framework is a framework for standardizing invocation, scheduling, execution, and control of asynchronous tasks according to a set of execution policies. Implementations are provided that allow tasks to be executed within the submitting thread, in a single background thread (as with events in Swing), in a newly created thread, or in a thread pool, and developers can create of Executor supporting arbitrary execution policies. The built-in implementations offer configurable policies such as queue length limits and saturation      policy which can improve the stability of applications by preventing runaway resource consumption.
• Concurrent Collections - Several new Collections classes have been added, including the new Queue and BlockingQueue interfaces, and high-performance, concurrent implementations of Map, List, and Queue.
• Atomic Variables - Classes for atomically manipulating single variables (primitive types or references), providing high-performance atomic arithmetic and compare-and-set methods. The atomic variable implementations in java.util.concurrent.atomicoffer higher performance than would be available by using synchronization (on most platforms), making them useful for implementing high-performance concurrent algorithms as well as conveniently implementing counters and sequence number generators.
• Synchronizers - General purpose synchronization classes, including semaphores,mutexes, barriers, latches, and exchangers, which facilitate coordination between threads.
• Locks - While locking is built into the Java language via the synchronized keyword, there are a number of inconvenient limitations to built-in monitor locks. The java.util.concurrent.locks package provides a high-performance lock implementation with the same memory semantics as synchronization, but which also supports specifying a timeout when attempting to acquire a lock, multiple condition variables per lock, non-lexically scoped locks, and support for interrupting threads which are waiting to acquire a lock.
• Nanosecond-granularity timing - The System.nanoTime method enables access to a nanosecond-granularity time source for making relative time measurements, and methods which accept timeouts (such as the BlockingQueue.offer, BlockingQueue.poll,Lock.tryLock, Condition.await, and Thread.sleep) can take timeout values in nanoseconds. The actual precision of System.nanoTime is platform-dependent.    

 Java 1.7 changes details like multi Exceptions catch block and Resource auto close able feather. 

Java 1.7 features