Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Try out compiling with tool as input to task

Relevant bits:

* JavaCompileWithJavaInstallationsIntegrationTest

* JavaCompile#getCompiler

    • -20
    • +18
    ./compile/AnnotationProcessingCompileTask.java
  1. … 13 more files in changeset.
Rename `o.g.a.i.lambdas.{Lambdas => SerializableLambdas}`

  1. … 6 more files in changeset.
Rename `o.g.a.i.lambdas.{Lambdas => SerializableLambdas}`

  1. … 6 more files in changeset.
Let `CompilerForkUtils` pass serializable lambda to `doNotCacheIf`

Let `CompilerForkUtils` pass serializable lambda to `doNotCacheIf`

Spike how toolchain support could look like

Relevant bits are in JavaToolchainCompileIntegrationTest

Basic idea is that the toolchain is configured on the JavaPluginExtension

Core tasks that require the toolchain (javac, javadoc, ) expose a toolchain property and add a convention to the extension.

Externals tasks (e.g. jlink) can do the same.

Build authors are able to add more tasks and set the toolchain accordingly (API is still missing to get/add the toolchains)

  1. … 8 more files in changeset.
WIP

  1. … 5 more files in changeset.
WIP

  1. … 1 more file in changeset.
WIP

  1. … 2 more files in changeset.
WIP

  1. … 2 more files in changeset.
WIP

  1. … 4 more files in changeset.
WIP

  1. … 7 more files in changeset.
Stream mapping to disk instead of keeping all elements in memory

    • -4
    • +10
    ./compile/SourceClassesMappingFileAccessor.java
  1. … 3 more files in changeset.
WIP

    • -4
    • +10
    ./compile/SourceClassesMappingFileAccessor.java
  1. … 3 more files in changeset.
Spike faster filtering

  1. … 1 more file in changeset.
Remove 'release' property (reverts #12648)

A more high level concept for specifying Java versions will

be introduced soon.

    • -6
    • +2
    ./compile/JavaCompilerArgumentsBuilder.java
  1. … 13 more files in changeset.
Remove 'release' property (reverts #12648)

A more high level concept for specifying Java versions will

be introduced soon.

    • -6
    • +2
    ./compile/JavaCompilerArgumentsBuilder.java
  1. … 13 more files in changeset.
Fix classloading

  1. … 2 more files in changeset.
Fix classloading

  1. … 1 more file in changeset.
Fix classloading

  1. … 1 more file in changeset.
Rework how the compiler plugin is loaded

The previous implementation had a performance regression due to the inclusion of `tools.jar`

on the worker classpath. Some classes of the Java compiler were loaded multiple times. To

avoid this, we need to separate the compiler plugin from Gradle itself, so that we can load

it in isolation in the same classloader as the loader which has `tools.jar`.

Therefore, the compiler plugin is restricted to plain Java APIs, and the "communication"

with Gradle, for example the intelligence of relativizing paths or writing the generated

mapping file, is done passing lambdas to the compiler.

Last but not least, this also means that the construction of the incremental compile task

has to be done via reflection (otherwise we would load the task in the wrong classloader).

    • -0
    • +23
    ./compile/IncrementalCompilationAwareJavaCompiler.java
    • -158
    • +0
    ./compile/IncrementalCompileTask.java
    • -1
    • +22
    ./compile/JavaHomeBasedJavaCompilerFactory.java
    • -8
    • +5
    ./compile/NormalizingJavaCompiler.java
    • -1
    • +4
    ./compile/SourceClassesMappingFileAccessor.java
  1. … 14 more files in changeset.
Rework how the compiler plugin is loaded

The previous implementation had a performance regression due to the inclusion of `tools.jar`

on the worker classpath. Some classes of the Java compiler were loaded multiple times. To

avoid this, we need to separate the compiler plugin from Gradle itself, so that we can load

it in isolation in the same classloader as the loader which has `tools.jar`.

Therefore, the compiler plugin is restricted to plain Java APIs, and the "communication"

with Gradle, for example the intelligence of relativizing paths or writing the generated

mapping file, is done passing lambdas to the compiler.

Last but not least, this also means that the construction of the incremental compile task

has to be done via reflection (otherwise we would load the task in the wrong classloader).

    • -0
    • +23
    ./compile/IncrementalCompilationAwareJavaCompiler.java
    • -158
    • +0
    ./compile/IncrementalCompileTask.java
    • -1
    • +22
    ./compile/JavaHomeBasedJavaCompilerFactory.java
    • -8
    • +5
    ./compile/NormalizingJavaCompiler.java
    • -1
    • +4
    ./compile/SourceClassesMappingFileAccessor.java
  1. … 14 more files in changeset.
Rework how the compiler plugin is loaded

The previous implementation had a performance regression due to the inclusion of `tools.jar`

on the worker classpath. Some classes of the Java compiler were loaded multiple times. To

avoid this, we need to separate the compiler plugin from Gradle itself, so that we can load

it in isolation in the same classloader as the loader which has `tools.jar`.

Therefore, the compiler plugin is restricted to plain Java APIs, and the "communication"

with Gradle, for example the intelligence of relativizing paths or writing the generated

mapping file, is done passing lambdas to the compiler.

Last but not least, this also means that the construction of the incremental compile task

has to be done via reflection (otherwise we would load the task in the wrong classloader).

    • -0
    • +23
    ./compile/IncrementalCompilationAwareJavaCompiler.java
    • -158
    • +0
    ./compile/IncrementalCompileTask.java
    • -1
    • +22
    ./compile/JavaHomeBasedJavaCompilerFactory.java
    • -8
    • +5
    ./compile/NormalizingJavaCompiler.java
    • -1
    • +4
    ./compile/SourceClassesMappingFileAccessor.java
  1. … 14 more files in changeset.
Rework how the compiler plugin is loaded

The previous implementation had a performance regression due to the inclusion of `tools.jar`

on the worker classpath. Some classes of the Java compiler were loaded multiple times. To

avoid this, we need to separate the compiler plugin from Gradle itself, so that we can load

it in isolation in the same classloader as the loader which has `tools.jar`.

Therefore, the compiler plugin is restricted to plain Java APIs, and the "communication"

with Gradle, for example the intelligence of relativizing paths or writing the generated

mapping file, is done passing lambdas to the compiler.

Last but not least, this also means that the construction of the incremental compile task

has to be done via reflection (otherwise we would load the task in the wrong classloader).

    • -0
    • +23
    ./compile/IncrementalCompilationAwareJavaCompiler.java
    • -158
    • +0
    ./compile/IncrementalCompileTask.java
    • -1
    • +22
    ./compile/JavaHomeBasedJavaCompilerFactory.java
    • -8
    • +5
    ./compile/NormalizingJavaCompiler.java
    • -1
    • +4
    ./compile/SourceClassesMappingFileAccessor.java
  1. … 14 more files in changeset.
WIP

    • -0
    • +23
    ./compile/IncrementalCompilationAwareJavaCompiler.java
    • -158
    • +0
    ./compile/IncrementalCompileTask.java
    • -1
    • +10
    ./compile/JavaHomeBasedJavaCompilerFactory.java
    • -8
    • +5
    ./compile/NormalizingJavaCompiler.java
    • -1
    • +4
    ./compile/SourceClassesMappingFileAccessor.java
  1. … 10 more files in changeset.
WIP

    • -0
    • +23
    ./compile/IncrementalCompilationAwareJavaCompiler.java
    • -158
    • +0
    ./compile/IncrementalCompileTask.java
    • -1
    • +10
    ./compile/JavaHomeBasedJavaCompilerFactory.java
    • -8
    • +5
    ./compile/NormalizingJavaCompiler.java
    • -1
    • +4
    ./compile/SourceClassesMappingFileAccessor.java
  1. … 13 more files in changeset.
Rework how the compiler plugin is loaded

The previous implementation had a performance regression due to the inclusion of `tools.jar`

on the worker classpath. Some classes of the Java compiler were loaded multiple times. To

avoid this, we need to separate the compiler plugin from Gradle itself, so that we can load

it in isolation in the same classloader as the loader which has `tools.jar`.

Therefore, the compiler plugin is restricted to plain Java APIs, and the "communication"

with Gradle, for example the intelligence of relativizing paths or writing the generated

mapping file, is done passing lambdas to the compiler.

Last but not least, this also means that the construction of the incremental compile task

has to be done via reflection (otherwise we would load the task in the wrong classloader).

    • -0
    • +23
    ./compile/IncrementalCompilationAwareJavaCompiler.java
    • -158
    • +0
    ./compile/IncrementalCompileTask.java
    • -1
    • +22
    ./compile/JavaHomeBasedJavaCompilerFactory.java
    • -8
    • +5
    ./compile/NormalizingJavaCompiler.java
    • -1
    • +4
    ./compile/SourceClassesMappingFileAccessor.java
  1. … 14 more files in changeset.
Rework how the compiler plugin is loaded

The previous implementation had a performance regression due to the inclusion of `tools.jar`

on the worker classpath. Some classes of the Java compiler were loaded multiple times. To

avoid this, we need to separate the compiler plugin from Gradle itself, so that we can load

it in isolation in the same classloader as the loader which has `tools.jar`.

Therefore, the compiler plugin is restricted to plain Java APIs, and the "communication"

with Gradle, for example the intelligence of relativizing paths or writing the generated

mapping file, is done passing lambdas to the compiler.

Last but not least, this also means that the construction of the incremental compile task

has to be done via reflection (otherwise we would load the task in the wrong classloader).

    • -0
    • +23
    ./compile/IncrementalCompilationAwareJavaCompiler.java
    • -158
    • +0
    ./compile/IncrementalCompileTask.java
    • -1
    • +22
    ./compile/JavaHomeBasedJavaCompilerFactory.java
    • -8
    • +5
    ./compile/NormalizingJavaCompiler.java
    • -1
    • +4
    ./compile/SourceClassesMappingFileAccessor.java
  1. … 14 more files in changeset.
Rework how the compiler plugin is loaded

The previous implementation had a performance regression due to the inclusion of `tools.jar`

on the worker classpath. Some classes of the Java compiler were loaded multiple times. To

avoid this, we need to separate the compiler plugin from Gradle itself, so that we can load

it in isolation in the same classloader as the loader which has `tools.jar`.

Therefore, the compiler plugin is restricted to plain Java APIs, and the "communication"

with Gradle, for example the intelligence of relativizing paths or writing the generated

mapping file, is done passing lambdas to the compiler.

Last but not least, this also means that the construction of the incremental compile task

has to be done via reflection (otherwise we would load the task in the wrong classloader).

    • -0
    • +23
    ./compile/IncrementalCompilationAwareJavaCompiler.java
    • -158
    • +0
    ./compile/IncrementalCompileTask.java
    • -1
    • +22
    ./compile/JavaHomeBasedJavaCompilerFactory.java
    • -8
    • +5
    ./compile/NormalizingJavaCompiler.java
    • -1
    • +4
    ./compile/SourceClassesMappingFileAccessor.java
  1. … 14 more files in changeset.
WIP

    • -0
    • +23
    ./compile/IncrementalCompilationAwareJavaCompiler.java
    • -158
    • +0
    ./compile/IncrementalCompileTask.java
    • -1
    • +19
    ./compile/JavaHomeBasedJavaCompilerFactory.java
    • -8
    • +5
    ./compile/NormalizingJavaCompiler.java
    • -1
    • +4
    ./compile/SourceClassesMappingFileAccessor.java
  1. … 13 more files in changeset.