Of invalid references to system libraries and execution environments

Picture this:

• You have a plugin that is supposed to be compatible with systems running even on 1.4 JRE i.e. your plugin execution environment is 1.4.
• An unsuspecting developer unintentionally checks out this plugin project into his workspace where he uses a 1.6 JRE by default.
• He starts writing Generics and is even allowed to do so because a 1.6 library is associated with the project in his workspace. The poor guy doesn't yet know what blunder he has done! :)

See an example below where in a plugin with 1.6 compliance, a developer accidentally used Autocloseable (coming from his workspace default 1.7 JRE).

API tooling provides a mechanism to figure out such illegal references to system libraries. In order to set up API tooling for your plugin project, right click on the project > PDE tools > API Tooling setup. Choose your project and click next. When it shows "Add API nature and API analysis builder", click finish. Now make sure your project settings for API tooling (right click > Properties > Plug-in development > API errors/warnings) are set as shown below:

By default, the "Supported Environments" will have no Execution Environments descriptions installed (From 3.8 onwards you will get an error whenever no execution environment description is installed). To install these EE descriptions, click on "install them now" or go to the "Install New Software.." page. Choose the "Eclipse Project update site" if already available or add the URL http://download.eclipse.org/eclipse/updates/<version> , where <version> = 3.6, 3.7, etc.

Uncheck "group by category" option and search for descriptions. Install these descriptions and you're all set to go. (Note: the above steps should be taken if you move to 3.8 Juno and suddenly find the "Missing EE descriptions" error in your project). 

Now with the above "invalid references to system libraries" option set to error/warning, you should get a warning for usage of Autocloseable in the above plugin project, as shown below:

These settings when done once on the project level and released into the repository will make sure that nobody accidentally references any API/class one is not supposed to. Read Olivier's post to know more about project vs. workspace settings

Eclipse Java 7 support

IF you're wondering what's going on with Java 7 work at Eclipse, here are some insights:

1. Eclipse 3.7(Indigo release) will not be shipped with Java 7 support. This is not because we folks at JDT are lazy and didn't want to do the whole work by the time 3.7 is wrapped up (Well, it might be true sometimes, but then we have tough taskmasters as well!!). This is mostly because the official release of Java 7 is scheduled on July 28, 2011, and we'd have already wrapped up 3.7 before that. The delay, in part, has also been caused due to the late availability of JSR-292 (Invoke Dynamic) and JSR-334 (Project Coin).

2. Eclipse folks are busy working overtime to make sure that Java 7 support is in place by the time we ship Eclipse 3.7.1. As per bug bug 288548- "The work for the Java 7 features is currently in progress in the 'BETA_JAVA7' branch and we will deliver separate updates for the stable builds in order to provide early access to the Java 7 features for interested parties."

3. Much of the compiler support is already in place, and some work needs to be done on the UI portion. To check the progress on BETA_JAVA7 branch, you can read through JDT Core java 7 wiki page. 

4. If you want to test Eclipse's java 7 support, or want to use Eclipse to try out the new java 7 stuff, you can follow the instructions given in the "What to do to set up the IDE" section of the JDT Core java 7 wiki page. We plan to have downloadable builds soon. You can see the list of open bugs against JDT/Core Java 7 support at any point in time here. To report new bugs, make sure you use the [1.7] tag.

Hope this helps!