# Getting Started with Eclipse 3.1 and J2SE 5.0

Eclipse 3.1 includes full support for the new features of J2SE 5.0 (codenamed "Tiger"). One of the most important consequences of this support is that you may not notice it at all--everything you expect to work for J2SE 1.4, including editing, compiling, debugging, quick fixes, refactorings, source actions, searching, etc., will work seamlessly with J2SE 5.0's new types and syntax. In this document, we will introduce some of the more interesting capabilities Eclipse users will find when working with J2SE 5.0.

## Prerequisites

In order to develop code compliant with J2SE 5.0, you will need a J2SE 5.0 Java Runtime Environment (JRE). If you start Eclipse for the first time using a J2SE 5.0 JRE, then it will use it by default. Otherwise, you will need to use the Installed JRE's dialog (Windows > Preferences > Java > Installed JRE's) to register it with Eclipse.

This document introduces some of the new language features in J2SE 5.0 very briefly, but it is not a proper tutorial for these features.

### Compiler Compliance Level

To use the new J2SE 5.0 features, you must be working on a project that has a 5.0 compliance level enabled. New projects can easily be marked as 5.0-compliant on the first page of the New > Project wizard:

To convert an existing J2SE 1.4 project to J2SE 5.0, you can simply:

1. Make sure you have a J2SE 5.0 JRE installed.
2. Start using the 5.0 features in your code.
3. When a compiler error is flagged, use Quick Fix to update the project's compliance level:

For more fine-tuned control, the compiler compliance level can be set globally for a workspace (Windows > Preferences > Java > Compiler) or individually for each project (from the project's context menu, choose Properties > Java Compiler). Projects with different compliance levels can co-exist in the workspace, and depend on each other. You can also fine-tune the kinds of compiler warnings and errors produced for each project using Properties > Java Compiler > Errors/Warnings > J2SE 5.0 Options

## Generic Types

Generic types allow objects of the same class to safely operate on objects of different types. For example, they allow compile-time assurances that a `List<String>` always contains `String`s, and a `List<Integer>` always contains `Integer`s.

Anywhere that Eclipse handles a non-generic type, it can handle a generic type:

- Generic types can be safely renamed.
- Type variables can be safely renamed.
- Generic methods can be safely extracted from / inlined into generic code.
- Code assist can automatically insert appropriate type parameters in parameterized types.

In addition, a new refactoring has been added: Infer Generic Type Arguments can infer type parameters for every type reference in a class, a package, or an entire project:

Invoking the refactoring produces:

Eclipse 3.1 provides new options when searching for references to generic types. Consider this example:

Selecting the reference to `List<Integer>` and using Search > References > Project will highlight the List types on all four lines:

Using the Search View menu, the results can be filtered:

Filter Incompatible leaves only references to types that are assignment-compatible with the selected type:

Filter Inexact leaves only type references with the exact same signature:

## Annotations

Annotations attach metadata about how Java types and methods are used and documented to the Java source and can then affect compilation or be queried at run-time. For example, `@Override` will trigger a compiler warning if the annotated method does not override a method in a superclass:

Everything you can do with a Java type, you can do with an annotation:

- Create new annotations using New > Annotation
- Refactor: rename, move, change signatures of members, etc.
- Search for occurrences
- Use code assist to fill in names and values

A very useful annotation with full support in Eclipse is `@SuppressWarnings`. For example, consider a private method that is currently unused, but you'd rather not delete:

Invoking quick fix on the warning proposes adding a `@SuppressWarnings` annotation:

Selecting the quick fix adds the annotation. The Eclipse compiler honors the annotation by removing the warning on `foo`:

## Enumerations

Enumerations are types that are instantiated at runtime by a known, finite set of objects:

Again, anything you can do to a Java class can be done to an enumeration:

- Create new enumerations using New > Enum
- Refactor: rename, move, rename constants, etc.
- Search for occurrences
- Use code assist to fill in constants

## Autoboxing

Autoboxing and auto unboxing allow for elegant syntax when primitive types are assigned to or retrieved from Object references:

Eclipse's source manipulation features handle autoboxing seamlessly, giving the correct types to new local variables and correct code assists. For code understanding, it is also possible to flag instances of autoboxing or autounboxing as compile warnings (Window > Preferences > Java > Compiler > Errors/Warnings > J2SE 5.0 Options > Boxing and unboxing conversions), or highlight them using syntax coloring (Window > Preferences > Java > Editor > Syntax Coloring > Java > Auto(un)boxed expressions):

## Enhanced for loop

For the common case of operating on each element of an array or collection in turn, J2SE 5.0 allows a new, cleaner syntax. Eclipse 3.1 provides a "foreach" code template that can automatically guess the collection to be iterated:

Choosing the template produces:

Eclipse 3.1 also provides a "Convert to enhanced for loop" quick-assist to upgrade 1.4-style `for` loops where possible.

## Other

All other features of J2SE 5.0 are handled flexibly by Eclipse's editing, searching, and code manipulation tools:

- Static imports
- Varargs
- Covariant return types

Happy coding!