Simplify mixing of ECJ and standard compilation tasks

[liblit]

In brief: I am using gradle-eclipse-compiler-plugin in a way that differs from its original intent. It’s working great, but uses some questionable hacks. I’d love to see my approach supported directly by this plugin, and thereby simplified.

Details:

The WALA program analysis framework uses Gradle’s standard Java compiler for most purposes. However, our automated tests also compile using ECJ to check for problems that Eclipse would report but that the standard compiler does not. gradle-eclipse-compiler-plugin has been a great help to us for those extra checks.

Until now, checking both standard and ECJ compilation required two Gradle runs, which in turn complicates testing and WALA contributor instructions. We would like to incorporate ECJ compilation tasks into the standard build validation process, meaning that we would have both standard compilation tasks and ECJ compilation tasks active in a single Gradle run. We want the regular Java compilation tasks (compileJava, compileTestJava, etc.) to remain unchanged, and we would add new ECJ compilation tasks with different names (compileJavaUsingEcj, compileTestJavaUsingEcj, etc.) and different destination directories to avoid conflicting with the standard tasks.

wala/WALA#744 achieves this. It works great! Regular compilation for builds, and extra ECJ compilations as part of check validation. But our approach is somewhat hackish. We cannot load gradle-eclipse-compiler-plugin in the usual way, since that would inject the ECJ toolchain into our standard Java compilation tasks. So instead we just start poking around in this plugin’s classes directly, in ways that you surely never intended when creating this plugin.

The main work happens here, in a class I created to serve as the ECJ counterpart of a Java SourceSet’s standard compilation task. Starting here you can see where we create an ECJ configuration extension, arrange dependencies, and ultimately create the EclipseCompilerToolchain instance.

Very sketchy, I know! Certainly our uses of EclipseCompilerBasePlugin.ECJ_EXTENSION and EclipseCompilerToolChain.create go beyond what the access qualifiers on those members should allow. I assume that Groovy is sneaking around this using reflection somehow. It works, but I almost feel it shouldn’t.

What would it take to support this use case more properly? Two things, I think:

1. The ability to load up the plugin in a way that does not replace the standard tool chain on all JavaCompile tasks.

2. A simple API for requesting an EclipseCompilerToolChain instance for a given ECJ version.

Are these things you would be interested in providing? Are you open to the kind of scenario I have described here? Or should I use your code as an example to build my own ECJ tool chain from scratch, independent of gradle-eclipse-compiler-plugin?

Many thanks for considering this request, and for any other suggestions you care to make!