GRADLE-3085: support arbitrary javax.tools.JavaCompiler for JavaCompiler task

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

GRADLE-3085: support arbitrary javax.tools.JavaCompiler for JavaCompiler task

Thomas Broyer
Hi,

I'd like to work on GRADLE-3085 [1] and would like guidance on how to proceed:

* how to configure the javax.tool.JavaCompiler to use in the DSL
* how to implement it
* how to test it

Looking at the current code, I think Gradle could expose some kind of JavaCompilerProvider on the JavaCompile task or its CompileOptions:

    interface JavaCompilerProvider {
      javax.tool.JavaCompiler getJavaCompiler();
    }

whose default implementation would be the current Jdk6JavaCompiler::findCompiler.

For my use-case which is about using Google ErrorProne [2], the implementation would:

1. build a ClassLoader with the error_prone JARs (read from a project configuration added by my gradle-errorprone-plugin [3]) that delegates to the current thread class loader
2. create an ErrorProneJavaCompiler [4] in that ClassLoader and return it

In step 2, I could even call the DefaultJavaCompilerProvider (or whichever JavaCompilerProvider was configured for the JavaCompile task before the ErrorProneJavaCompilerProvider is plugged in) to inherit its handling of the java.home system property, and pass the created JavaCompiler to the ErrorProneJavaCompiler constructor.

Another approach would be to configure the JavaCompiler class and its classpath in the DSL, and let the Jdk6JavaCompiler instantiate it (create a ClassLoader from the configured classpath, create an instance of the configured class in that ClassLoader; this logic would be hidden in the Jdk6JavaCompiler).

What do you think?

Would that work with the "fork" option? (I think so, but I'm relatively new to Gradle's code)
Is there any other option that needs to be tested (and possibly dealt with) ?

About testing, how would you do it? Duplicate InProcessJavaCompilerIntegrationTest and DaemonJavaCompilerIntegrationTest with an overridden compilerConfiguration that configures a custom JavaCompiler? (how would you test that it's correctly used then? make it emit some diagnostic message?) or rather add a test method in JavaCompilerIntegrationSpec (but then it would be called by CommandLineJavaCompilerIntegrationTest whereas its behavior would be overwritten there, so it would have to be disabled if the test checks that the custom JavaCompiler has been used).

Thanks in advance!


[3] https://github.com/tbroyer/gradle-errorprone-plugin, BTW feedback on the DSL would be very welcome!

--
Thomas Broyer
/tɔ.ma.bʁwa.je/
Reply | Threaded
Open this post in threaded view
|

Re: GRADLE-3085: support arbitrary javax.tools.JavaCompiler for JavaCompiler task

Adam Murdoch

On 7 Jun 2014, at 9:41 am, Thomas Broyer <[hidden email]> wrote:

Hi,

I'd like to work on GRADLE-3085 [1] and would like guidance on how to proceed:

* how to configure the javax.tool.JavaCompiler to use in the DSL
* how to implement it
* how to test it

Looking at the current code, I think Gradle could expose some kind of JavaCompilerProvider on the JavaCompile task or its CompileOptions:

    interface JavaCompilerProvider {
      javax.tool.JavaCompiler getJavaCompiler();
    }

I think what we want to do here is model the Java compiler as a toolchain, similar to what we’re doing for the native C/C++ languages.

A toolchain is essentially just a factory for tools that do some work - the java compiler in this instance. There would be a few different implementations - one that uses the compiler from the current jdk, and one that uses an installed jdk. There can then also be other implementations: one that uses error_prone, one that uses the Eclipse compiler, one that uses the aspectj compiler, and so on.

A project would have a set of available java toolchains, from which the build author can select a particular implementation. Each JavaCompile task (and GroovyCompile and ScalaCompile task for joint compilation) would have an associated toolchain instance. There should also be a project level default toolchain.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com

Reply | Threaded
Open this post in threaded view
|

Re: GRADLE-3085: support arbitrary javax.tools.JavaCompiler for JavaCompiler task

Thomas Broyer



On Sat, Jun 7, 2014 at 11:28 PM, Adam Murdoch <[hidden email]> wrote:

On 7 Jun 2014, at 9:41 am, Thomas Broyer <[hidden email]> wrote:

Hi,

I'd like to work on GRADLE-3085 [1] and would like guidance on how to proceed:

* how to configure the javax.tool.JavaCompiler to use in the DSL
* how to implement it
* how to test it

Looking at the current code, I think Gradle could expose some kind of JavaCompilerProvider on the JavaCompile task or its CompileOptions:

    interface JavaCompilerProvider {
      javax.tool.JavaCompiler getJavaCompiler();
    }

I think what we want to do here is model the Java compiler as a toolchain, similar to what we’re doing for the native C/C++ languages.

A toolchain is essentially just a factory for tools that do some work - the java compiler in this instance. There would be a few different implementations - one that uses the compiler from the current jdk, and one that uses an installed jdk. There can then also be other implementations: one that uses error_prone, one that uses the Eclipse compiler, one that uses the aspectj compiler, and so on.

A project would have a set of available java toolchains, from which the build author can select a particular implementation. Each JavaCompile task (and GroovyCompile and ScalaCompile task for joint compilation) would have an associated toolchain instance. There should also be a project level default toolchain.

Sounds great! 

When do you think it'd be ready?
I'm almost ready to submit a pull request for what I proposed; so it could possibly be used in the mean time, if you think it's worth it.

If I can help in any way, I'll gladly do (at the very least, I'll try to test it as soon as it's available)

--
Thomas Broyer
/tɔ.ma.bʁwa.je/
Reply | Threaded
Open this post in threaded view
|

Gradle pull requests in github sitting idle

Biswa Dahal
Hi:

I made a contribution a while back and it's pull request hasn't been pulled yet. This applies to a number of other pull requests that passed CI build.

Are these sitting there because they're incorrect/ undesirable or is there a plan to pull them (or reject them) at some point in the future.

If they are missing anything, how do we know what that is?

BD


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GRADLE-3085: support arbitrary javax.tools.JavaCompiler for JavaCompiler task

Adam Murdoch
In reply to this post by Thomas Broyer

On 7 Jun 2014, at 3:57 pm, Thomas Broyer <[hidden email]> wrote:




On Sat, Jun 7, 2014 at 11:28 PM, Adam Murdoch <[hidden email]> wrote:

On 7 Jun 2014, at 9:41 am, Thomas Broyer <[hidden email]> wrote:

Hi,

I'd like to work on GRADLE-3085 [1] and would like guidance on how to proceed:

* how to configure the javax.tool.JavaCompiler to use in the DSL
* how to implement it
* how to test it

Looking at the current code, I think Gradle could expose some kind of JavaCompilerProvider on the JavaCompile task or its CompileOptions:

    interface JavaCompilerProvider {
      javax.tool.JavaCompiler getJavaCompiler();
    }

I think what we want to do here is model the Java compiler as a toolchain, similar to what we’re doing for the native C/C++ languages.

A toolchain is essentially just a factory for tools that do some work - the java compiler in this instance. There would be a few different implementations - one that uses the compiler from the current jdk, and one that uses an installed jdk. There can then also be other implementations: one that uses error_prone, one that uses the Eclipse compiler, one that uses the aspectj compiler, and so on.

A project would have a set of available java toolchains, from which the build author can select a particular implementation. Each JavaCompile task (and GroovyCompile and ScalaCompile task for joint compilation) would have an associated toolchain instance. There should also be a project level default toolchain.

Sounds great! 

When do you think it'd be ready?
I'm almost ready to submit a pull request for what I proposed; so it could possibly be used in the mean time, if you think it's worth it.

There’s some stuff in master already (as of not very long ago). Each JavaCompile task has an associated JavaToolChain. Your plugin could then provide its own implementation.

At this stage, you still need to use internal stuff to implement a JavaToolChain. Over time we can open up some public APIs to make this easier.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com

Reply | Threaded
Open this post in threaded view
|

Re: GRADLE-3085: support arbitrary javax.tools.JavaCompiler for JavaCompiler task

Thomas Broyer



On Thu, Jun 12, 2014 at 12:18 AM, Adam Murdoch <[hidden email]> wrote:

On 7 Jun 2014, at 3:57 pm, Thomas Broyer <[hidden email]> wrote:




On Sat, Jun 7, 2014 at 11:28 PM, Adam Murdoch <[hidden email]> wrote:

On 7 Jun 2014, at 9:41 am, Thomas Broyer <[hidden email]> wrote:

Hi,

I'd like to work on GRADLE-3085 [1] and would like guidance on how to proceed:

* how to configure the javax.tool.JavaCompiler to use in the DSL
* how to implement it
* how to test it

Looking at the current code, I think Gradle could expose some kind of JavaCompilerProvider on the JavaCompile task or its CompileOptions:

    interface JavaCompilerProvider {
      javax.tool.JavaCompiler getJavaCompiler();
    }

I think what we want to do here is model the Java compiler as a toolchain, similar to what we’re doing for the native C/C++ languages.

A toolchain is essentially just a factory for tools that do some work - the java compiler in this instance. There would be a few different implementations - one that uses the compiler from the current jdk, and one that uses an installed jdk. There can then also be other implementations: one that uses error_prone, one that uses the Eclipse compiler, one that uses the aspectj compiler, and so on.

A project would have a set of available java toolchains, from which the build author can select a particular implementation. Each JavaCompile task (and GroovyCompile and ScalaCompile task for joint compilation) would have an associated toolchain instance. There should also be a project level default toolchain.

Sounds great! 

When do you think it'd be ready?
I'm almost ready to submit a pull request for what I proposed; so it could possibly be used in the mean time, if you think it's worth it.

There’s some stuff in master already (as of not very long ago). Each JavaCompile task has an associated JavaToolChain. Your plugin could then provide its own implementation.

At this stage, you still need to use internal stuff to implement a JavaToolChain. Over time we can open up some public APIs to make this easier.


master will become 2.1, right?
so 2.0 gives me no alternative other than forking a JVM (java -cp <error_prone classpath> com.google.errorprone.ErrorProneCompile <javac arguments>) ?
 
--
Thomas Broyer
/tɔ.ma.bʁwa.je/