I don’t use the JDTCompiler for anything I do, but it seems like using the
JavaCompile task wasn’t the correct domain modeling here. Even though it worked, it seems like it might have been more of a work-around. The
JavaCompile task provides an API that models the options of the JDK’s compiler. The change from specifying executable to Java home should be more conventional for a user wanting to point to a specific JDK, rather than drilling down the executable.
As the JDTCompiler batch compiler is a Java executable, I would expect that a better model would be to create a
JDTCompile task that extends
AbstractCompile and calls
javaexec to handle which models this particular specification of a compiler. The properties available from the superclasses should have most of what you need that was not too specific to
javac. Anything additional that is specific to the JDTCompiler can then be in the class specifically for it.
This also seems like a pretty good case for plugin that could be published to the portal.