Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Separate defineClass and decorateClass (#6028)

After https://github.com/gradle/gradle/pull/5811 is merged, I was surprised that the illegal reflective access warnings still appear:

> Illegal reflective access using Lookup on org.gradle.internal.classloader.ClassLoaderUtils

It turns out that a lookup object which is accessible to the target class class loader must be provided. For example, if we want to invoke `MyClassLoader.defineClass` via `Lookup`, we must provide a lookup object from `privateLookupIn(MyClassLoader.class)`, not `privateLookupIn(ClassLoader.class)`. Otherwise, we'll get the warning and potential failure in the future.

See more information in the https://mydailyjava.blogspot.com/2018/04/jdk-11-and-proxies-in-world-past.html

Also, this PR does a tiny improvement: it uses `Lookup.defineClass` as much as possible. `Lookup.defineClass` is expected to replace `Unsafe.defineClass` by JDK team, but `Lookup.defineClass` has a limitation: it can only `defines a class to the same class loader and in the same runtime package and protection domain as this lookup's lookup class`. If we're decorating a class, this is gonna be fine and we use this API, otherwise we use `Lookup` to invoke `ClassLoader.defineClass` as a fallback.

  1. … 4 more files in changeset.
Rationalise handling of “current” build operation and build operation ID

For an upcoming change to emit console logging as build operation progress events, we need to associate all progress logging with the build operation. This pulled a thread on some long overdue cleanup.

The end result is:

1. Base build operation infrastructure is consolidated org.gradle.internal.operations.

2. Mechanism for passing thread global current build operation is more test friendly, and better named.

3. A consistent mechanism is used for binding the current operation to the thread, instead of two mechanisms.

4. Build operation IDs are typed to OperationIdentifier.

There is no public API or user behaviour change.

  1. … 147 more files in changeset.
Change test to run two successive builds using the GradleBuild task

This test was endangered to be flaky. Running two builds in a row,

there is never a guarantee that they will run on the same daemon.

Clarify that only builds started by a GradleBuild task cause the issue

Add tests for: build operation ids are unique for nested builds

#2622

  1. … 2 more files in changeset.
Unify BuildOperationExecutor and BuildOperationProcessor APIs

This introduces the following `BuildOperationExecutor`

interface (as outlined in gradle/gradle#1676):

void run(RunnableBuildOperation buildOperation);

<T> T call(CallableBuildOperation<T> buildOperation);

<O extends RunnableBuildOperation> void runAll(

Action<BuildOperationQueue<O>> schedulingAction);

<O extends BuildOperation> void runAll(

BuildOperationWorker<O> worker,

Action<BuildOperationQueue<O>> schedulingAction);

To accomplish this, the following changes were performed:

- Various representation of build operations have been merged into

1) BuildOperation (with sub-interfaces)

-> declare and describe a build operation

2) BuildOperationDescriptor (BuildOperationDescriptor.Builder)

-> describe a build operation

3) BuildOperationState

-> represents a running build operation, with run state, start time,

parent relationship information, and description

- The DefaultBuildOperationExecutor and DefaultBuildOperationProcessor

implementations have been merged in DefaultBuildOperationExecutor,

which is now build session scoped.

    • -0
    • +72
    ./groovy/org/gradle/internal/operations/BuildOperationExecutorParallelExecutionIntegrationTest.groovy
  1. … 179 more files in changeset.
Fix tests according to review comments

  1. … 2 more files in changeset.
Refine BuildOperation[Executor|WorkerRegistry] integ tests

  1. … 1 more file in changeset.
Worker lease and build operation for the whole build execution

DefaultGradleLauncher now holds a worker lease around the whole build

execution. This will allow for worker lease management at configuration

time.

It now also emits a ‘Run build’ build operation around the whole build

execution. Previously it was only emitted when executing a build through

TAPI.

  1. … 8 more files in changeset.
Removing unintentional sleep from integration test

+review REVIEW-5884

Fix for issue with canceling running oprations

+review REVIEW-5884

  1. … 1 more file in changeset.
Removing race condition from BuildOperationProcessor integration test

Disabling test for now until it can be improved

Disabling test for now until it can be improved

More test coverage and better exception handling for parallel test report generation.

+review REVIEW-5884

  1. … 2 more files in changeset.
Cleanup of SystemProperties integration test

+review REVIEW-5763

  1. … 1 more file in changeset.
Further refactoring of System Property handling in Zinc compiler

+review REVIEW-5763

  1. … 2 more files in changeset.
Better handling of System Property during Zinc Compile

+review REVIEW-5763

  1. … 3 more files in changeset.
Can reuse existing concurrency functionality from ConcurrentSpec.

+review REVIEW-5397

  1. … 1 more file in changeset.
Pushed synchronization logic into SystemProperties for reusability.

+review REVIEW-5397

  1. … 4 more files in changeset.