# Incompatibilities between Eclipse 3.5 and 3.6

Eclipse changed in incompatible ways between 3.5 and 3.6 in ways that affect plug-ins. The following entries describe the areas that changed and provide instructions for migrating 3.5 plug-ins to 3.6. Note that you only need to look here if you are experiencing problems compiling or running your 3.5 plug-in on 3.6.

1. SDK ships 2 org.junit plug-ins (versions 3.8.2 and 4.8.1)
2. Source incompatibility for subclasses of `AbstractTemplatesPage`
3. `@SuppressWarnings("unchecked")` does not ignore raw types warnings anymore
4. Classpath containers have the choice to resolve the referenced libraries themselves

## 1. SDK ships 2 org.junit plug-ins (versions 3.8.2 and 4.8.1)

What is affected: Clients that require the org.junit and don't include 4.x in their version bounds

Description: The SDK now ships 2 org.junit plug-ins (versions 3.8.2 and 4.8.1). Clients that want to run JUnit Plug-in Tests with a Java 5 or later VM and that require org.junit with a version bound that does not include 4.x need to update their version bound to include 4.x (e.g. change their `Require-Bundle:` header to `org.junit;bundle-version="3.8.2"`). If they don't update their bounds, both versions of org.junit are resolved at run time, which leads to errors when test classes are loaded.

For complete details on the steps required to transition to using JUnit4 or to continue using JUnit3, please see:
http://wiki.eclipse.org/Eclipse/Testing/JUnit4_Changes.

Action required: Clients that require org.junit should make sure they include 4.x in their required version bounds.

## 2. Source incompatibility for subclasses of `AbstractTemplatesPage`

What is affected: Subclasses of `org.eclipse.ui.texteditor.templates.AbstractTemplatesPage`.

Description: In order to provide new API we had to make two methods public. While this does not break binary compatibility it breaks source compatibility.

Action required: Change the visibility of `getSelectedTemplates()` and `getTemplateStore()` to `public`.

## 3. `@SuppressWarnings("unchecked")` does not ignore raw types warnings anymore

What is affected: Usage of `@SuppressWarnings("unchecked")`.

Description: Up to Eclipse 3.5, `@SuppressWarnings("unchecked")` was used to suppress the unchecked and raw types warnings. This was not consistent with other compilers (e.g. javac). A new warning token `"rawtypes"` has been added to cover the case of raw type warnings exclusively. So in order to get rid of all warnings, in Eclipse 3.6, it might be required to add `"rawtypes"` in the warning token list.

If it is not possible to update the code, a system property (`-DsuppressRawWhenUnchecked=true`) can be added to the `-vmargs` list on startup. This preserves the old behavior. The projects need to be manually cleaned and rebuilt after toggling the property.

Action required: When new warnings that were previously ignored are now reported, add `"rawtypes"` to the list of warning tokens.

Before:

    @SuppressWarnings("unchecked")
        void bar(List list) {
            List<String> ls2 = list;
        }
    @SuppressWarnings("unchecked")
    private List l;

After:

    @SuppressWarnings({"unchecked", "rawtypes"})
        void bar(List list) {
            List<String> ls2 = list;
        }
    @SuppressWarnings("rawtypes")
    private List l;

## 4. Classpath containers have the choice to resolve the referenced libraries themselves

What is affected: Classpath containers that depended on JDT to resolve referenced libraries via JAR's MANIFEST.MF.

Description: In 3.5, classpath containers did not have full control over what JARs ended up on the classpath, since references in the Class-Path section of a JAR's MANIFEST.MF were automatically added. In 3.6, referenced JARs are not automatically added any more. However, a classpath container implementor can use `JavaCore#getReferencedClasspathEntries()` to resolve the referenced JARs and return them in the implementation of `IClasspathContainer#getClasspathEntries()`.

Please refer to the documentation of these APIs:

- `IClasspathContainer`
- `JavaCore#getReferencedClasspathEntries()`

Action required: If the classpath container implementation cannot be changed to accommodate this, the 3.5 behavior can be retained by adding a system property (`-DresolveReferencedLibrariesForContainers=true`) to the `-vmargs` list on start-up.