Remove “Build path specifies execution environment…” warnings from Problems View

I have often workspaces with projects which specify Java 1.5 as minimal execution environment. On my machine there is no JDK 1.5 installed, and it turns out that getting one for Mac OSX Mountain Lion is not trivial. Actually I don’t need a JDK 1.5, since the standard 1.6 JDK is compatible. However, this raises in the workspace these annoying warnings.

screenshot 2013-05-17 um 10.32.31

In the Execution Environments setting it is possible to mark the Java 1.6 installation as compatible to the J2SE-1.5 Execution Environment:

screenshot 2013-05-17 um 10.52.31

Although the JDK 1.6 is marked compatible now, it is not “strictly compatible”, so the warning message remains.

Next you could try to disable the warning message. There is a setting for this in the preference dialog Java/Compiler/Building:

screenshot 2013-05-17 um 10.35.17

After changing the setting you are asked to rebuild the projects. But again, the warning do not disappear. I suspect this to be a bug and raised Bug#408317 for this.

So the last chance is to filter these warnings. Therefore select the options menu in the Problems View and open the “Configure Contents” dialog. In the “Types” selection tree expand the “Java Build Path Problems” node and uncheck “JRE System Library Problem”.

screenshot 2013-05-17 um 11.03.53

Finally the warning messages disappear from the Problems View. However, they are just filtered from the view, the projects themselves will still have these resource markers, so you will have a warning overlay icon on the project in the Package Explorer View although the Problems View might be empty.

But this raises the next problem: Now the warning disappears and the code is compiled with Java 1.6, and thus against the 1.6 API. This leads to the problem that you could accidently use API from >= 1.6. For example, usage of String#isEmpty() would compile even if the Execution Environment is set to J2SE-1.5 (the Execution Environment anyway just defines the lowest requirement) and also if Java source compatibility is set to 1.6 in the compiler settings.

We need to detect this unwanted use of API that is not 1.5 compatible. Therefore the PDE tooling offers support to install an Execution Environment Description for J2SE-1.5 and set up API tooling. This will finally allow us to detect illegal API use:

screenshot 2013-05-17 um 14.00.15

I like to thank Laurent Goubet and Mikael Barbero for their valuable comments on the potential API problems.

Using the JDT compiler in normal Maven builds

The Maven Compiler Plugin can be customized to use a different compiler than Javac. One of the options listed for the compilerId setting is “eclipse“. To use it you will have to add a dependency to the plexus-compiler-eclipse (current version: 1.8.1).

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-compiler-plugin</artifactId>
	<configuration>
		<compilerId>eclipse</compilerId>
		<source>1.5</source>
		<target>1.5</target>
		<optimize>true</optimize>
	</configuration>
	<dependencies>
		<dependency>
			<groupId>org.codehaus.plexus</groupId>
			<artifactId>plexus-compiler-eclipse</artifactId>
			<version>1.8.1</version>
			<scope>runtime</scope>
		</dependency>
	</dependencies>
</plugin>

A pitfall here is that the compiler compliance level is not automatically set through the target setting. You have to set also optimize=true. Otherwise Java 1.5 sources won’t compile.

The plexus-compiler-eclipse (version 1.8.1) takes a rather old version of JDT, 3.3.0-v_771. To use another version you will have to deploy a newer version of JDT yourself into your repository and list this dependency before plexus-compiler-eclipse.

Misleading error message for JavaBeautifier dependencies

The postprocessor org.eclipse.xpand2.output.JavaBeautifier comes with the plugin org.eclipse.xpand, but needs additional dependencies to work. Under the hood the beautifier leverages JDT, so the dependency to JDT is obvious. Normally the missing plugin dependencies can be easily derived from the error messages, since the package name of some missing class usually maps to the plugin identifier where the class resides. However, you might recognize the error message
java.lang.NoClassDefFoundError: org/eclipse/jface/text/BadLocationException
and think that the class must be in plugin org.eclipse.jface.text. But that’s not true, although there is of course a plugin org.eclipse.jface.text. Actually, class BadLocationException is in the plugin org.eclipse.text and is reexported from the JFace plugin.

The actual dependencies that have to be added when using the JavaBeautifiers are:

  • org.eclipse.jdt.core
  • org.eclipse.text
  • org.eclipse.core.resources
  • org.eclipse.core.runtime