Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Address compiler warnings in 'language-groovy' subproject

Address compiler warnings in 'language-groovy' subproject

Address compiler warnings in 'language-groovy' subproject

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).

  1. … 20 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).

  1. … 20 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).

  1. … 20 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).

  1. … 20 more files in changeset.
WIP

  1. … 16 more files in changeset.
WIP

  1. … 19 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).

  1. … 20 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).

  1. … 20 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).

  1. … 20 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).

  1. … 20 more files in changeset.
WIP

  1. … 19 more files in changeset.
WIP

  1. … 19 more files in changeset.
WIP

  1. … 19 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

  1. … 24 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

  1. … 24 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

  1. … 24 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

  1. … 24 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

  1. … 24 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

  1. … 24 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

  1. … 24 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

  1. … 24 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

  1. … 24 more files in changeset.
Add compilation support for Java modules using the --module-path

  1. … 24 more files in changeset.
Fix tasks and plugins that were using Task.project at execution time

Signed-off-by: Paul Merlin <paul@gradle.com>

  1. … 21 more files in changeset.
Fix tasks and plugins that were using Task.project at execution time

Signed-off-by: Paul Merlin <paul@gradle.com>

  1. … 19 more files in changeset.
Fix tasks and plugins that were using Task.project at execution time

Signed-off-by: Paul Merlin <paul@gradle.com>

  1. … 20 more files in changeset.
Add NotYetImplementedASTTransformation to disallowed Groovy compiler classloader classes