To improve performance, the new index captures a lot of semantic information in an index file separate from the classic index file, consuming additional memory and disk space. The new Rebuild Index button can be used to delete the existing index files - both classic as well as new - then rebuild these index files from scratch. If Enable new Java index option is not checked, only the classic index file will be rebuilt though both will be deleted, thus saving disk space. Also, if index corruption is suspected, Rebuild Index can be used to start from a clean slate again.

Eclipse 4.7 contains an experimental new Java index which is disabled by default. As a thumb rule, you can try the new indexing to get better performance when there are a large number of Jar dependencies. The new index has been adopted completely in the Type Hierarchy view and partially in some features that use the binary file caching (jars and .class files) such as Package Explorer expansion for jars. It hasn’t been adopted by the search features.

This allows processors to compile Java sources using the Java project’s settings without manually maintaining this information in the processor options.

Warnings for unlikely argument types

Many developers have learned the hard way, that certain uses of Java collections that pass the compiler’s type check, may still contain "type errors", resulting in unexpected runtime behaviour. A new analysis has been added to the Eclipse compiler for Java that will detect the most common bugs in this area.

The common reason behind this problem is the fact that not all methods of those collection types make use of generics in the way one might expect. As a result it is possible to create a Set<Short> , whose add(Short) method will only accept arguments of type Short , yet method remove(Object) will happily accept literally any argument, because the method’s parameter has type Object .

Here is a code snippet that seems to add and remove the same element from the set, but at a closer look the remove call has no effect. What is difficult to see for the naked eye is now flagged by a new warning:

In a simple world, this would be all there is to say, but over time people have developed various code patterns that rely on these overly general signatures. Consider the following use of subtyping:

Depending on your coding style this may or may not be accepted as a legitimate short hand for:

if (n instanceof Short) set.remove((Short) n);

To reduce the churn caused by the new analysis, we developed some heuristics that filter out cases where types are "sufficiently similar", so the above goes unwarned.

As with any heuristic, there is no clear line. This implies that the compiler may show "unwanted" warnings, or filter out invocations that are in fact bugs. For the former case, @SuppressWarnings("unlikely-arg-type") will document the exception both for the user and for the compiler. For the latter case, we provide an option to tighten the rules, namely to apply strict type compatibility checks instead of said heuristics. For this extra scrutiny you may enable the sub-option Perform strict analysis against the expected type in Preferences > Java > Compiler > Errors/Warnings > Potential programming problems.