Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add missing @Override to all modules

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

  1. … 999 more files in changeset.
Add `JavaReflectionUtil#getFieldOrNull` to help in Task field validation

  1. … 1 more file in changeset.
Delegate `CollectionUtils#collect` for `Iterable` to `Collection`, when applicable

  1. … 4 more files in changeset.
Detangle caching and look-up in TypeInspector

    • -0
    • +40
    ./CachedTypeInspector.java
    • -0
    • +98
    ./DefaultTypeInspector.java
    • -0
    • +25
    ./TypeInspectorFactory.java
  1. … 3 more files in changeset.
Move TypeInspector to base-services

    • -0
    • +107
    ./TypeInspector.java
  1. … 7 more files in changeset.
Cleanup for #8650 (#8663)

* Improve test for hasTypeVariable

* Move resolving type variables to model core

* Add more test coverage for resolving type variables

  1. … 6 more files in changeset.
Move resolving type variables to model core

  1. … 6 more files in changeset.
Revert "Move resolving to JavaReflectionUtil"

Using `TypeToken` in `JavaReflectionUtils` increases the size of the

toolingApi jar - let's not do this for now.

This reverts commit 45be1364fae34cf72fc0f3370dffddcf0254768e.

  1. … 3 more files in changeset.
Move resolving to JavaReflectionUtil

  1. … 3 more files in changeset.
Fix performance regression introduced by using TypeToken to resolve type variables (#8650)

Only use type token to resolve type variables if there are type variables to resolve.

  1. … 3 more files in changeset.
Rename factory methods on JavaMethod

  1. … 20 more files in changeset.
Address review feedback

    • -0
    • +31
    ./CachedInvokable.java
  1. … 3 more files in changeset.
Split methods required in Worker

  1. … 17 more files in changeset.
Move most of org.gradle.internal.reflect to modelCore

The JavaMethod and DirectInstantiator classes are used by the service

and classloading infrastructure in `baseServices`, so I would leave

them there for now.

  1. … 49 more files in changeset.
Move JavaMethod factory methods to JavaMethod

  1. … 21 more files in changeset.
Simplify PropertyExtractor constructor

Add more validation of inject annotations.

- Don't allow an inject annotation on any method of a type for which it is not relevant, e.g. `@Workspace` on a `Task` (was only applied to getters previously).

- Don't allow multiple inject annotations on the same getter (received a cryptic error message previously).

- Don't allow inject annotations on private methods, setter methods, static methods and getter methods that cannot be overridden (was applied only to `@Inject` previously).

- Don't allow inject annotations on methods of `ExtensionAware` (received a cryptic error message previously).

  1. … 7 more files in changeset.
Extract an interface out of `ServiceRegistry` to include only the pieces needed for injection by the instantiator infrastructure. This will evolve to allow different annotations to be handled differently, but for now it simply behaves the same way as before.

Use a custom implementation of this interface for artifact transform instantiation, to avoid the cost of setting up a full mutable registry (for now).

  1. … 21 more files in changeset.
Bust up some of the internals of the class generator, to allow different pieces to be composed. Add some more validation to where `@Inject` can be used.

  1. … 5 more files in changeset.
Fail class decoration for a class with any abstract methods for which an implementation will not be provided by the generated subclass. Improve property inspection to better understand getter methods with covariant return types.

  1. … 6 more files in changeset.
Adjust copyright header years

  1. … 1 more file in changeset.
Ignore fewer methods

  1. … 2 more files in changeset.
Move PropertyExtractor to base services

    • -0
    • +356
    ./PropertyExtractor.java
    • -0
    • +40
    ./PropertyMetadata.java
  1. … 9 more files in changeset.
Replace most direct usages of `DirectInstantiator` with indirect usages via `InstantiatorFactory` or test fixtures instead. This means more consistent behaviour in unit tests because the objects under test will behave more similarly to how they do at runtime. This also allows the decision of how the instantiation should behave to live in as few places as possible, so this can be more easily evolved and contextualized.

  1. … 60 more files in changeset.
Fix handling of InterruptedExceptions

These exceptions were handled incorrectly throughout the whole

codebase, usually rethrown without restoring the interrupt status

or discarded entirely. This means that the system would not stop

executing even though the user wanted it to. In some cases this

also left the system in an inconsistent state, leading to deadlocks.

The most notable changes include:

- UncheckedException.rethrow automatically restores the interrupt status

- AsyncDispatch is guaranteed to deliver its messages, even when interrupted

- ExecHandle cancels the started process if it is interrupted while waiting

- ExecHandle disconnects from the process' output before killing it

- The worker API cancels the started work items if it is interrupted

- ManagedExecutors shut down immediately if they are interrupted while stopping

- We no longer log exceptions caused by interruption to the console

- Interrupting our caches no longer leaks file locks

  1. … 38 more files in changeset.
Remove deprecated Class.newInstance() (#6496)

`Class.newInstance()` was deprecated in Java 9.

  1. … 34 more files in changeset.
Add initial support component metadata supplier caching

This commit adds the infrastructure for caching of component metadata rules.

For now, the only kind of rule we can cache are the component metadata supplier

rules, which are used during dynamic version selection, but the executor

infrastructure can be reused to cache more kinds of rules.

The implementation relies on the principal that a "rule" can be safely cached if:

- the rule has no side effect, and uses the "class-based pattern"

- the implementation of the rule didn't change

- the inputs of the rule didn't change

For this, we introduce a new persistent cache (hence cross-build) with an in-memory

facing cache, that allows us to avoid the execution of a rule if the result is

already in the cache. The implementation makes use of _snapshotting_ to capture the

state of the inputs of a rule, which consists of the implementation of the rule and

its potential parameters. It's worth noting that at this stage we do not consider

the services the rule can use, it's going to be done in a subsequent commit.

This worked required a clarification of what an rule cares about (the result) in

opposition to what the user is faced with. For example, a component metadata supplier

rule output is a `ComponentMetadata`, but what we offer to the user, to build that

metadata, is a `ComponentMetadataSupplierDetails` instance. Similarly, component

metadata rules would have different kind of output and what the user manipulates.

The cache works with a primary key (for the first implemented cache, the key is the

module version identifier) and will invalidate the results based on the cache policy

(should refresh modules).

The persistent cache uses the snapshot as the key in the store. In theory, should we

consider that we have a nearly perfect hash function, we could instead use the hash

of the snapshot as the key. Measurements would have to be made to check if it's worth

implementing.

  1. … 46 more files in changeset.
Add initial support component metadata supplier caching

This commit adds the infrastructure for caching of component metadata rules.

For now, the only kind of rule we can cache are the component metadata supplier

rules, which are used during dynamic version selection, but the executor

infrastructure can be reused to cache more kinds of rules.

The implementation relies on the principal that a "rule" can be safely cached if:

- the rule has no side effect, and uses the "class-based pattern"

- the implementation of the rule didn't change

- the inputs of the rule didn't change

For this, we introduce a new persistent cache (hence cross-build) with an in-memory

facing cache, that allows us to avoid the execution of a rule if the result is

already in the cache. The implementation makes use of _snapshotting_ to capture the

state of the inputs of a rule, which consists of the implementation of the rule and

its potential parameters. It's worth noting that at this stage we do not consider

the services the rule can use, it's going to be done in a subsequent commit.

This worked required a clarification of what an rule cares about (the result) in

opposition to what the user is faced with. For example, a component metadata supplier

rule output is a `ComponentMetadata`, but what we offer to the user, to build that

metadata, is a `ComponentMetadataSupplierDetails` instance. Similarly, component

metadata rules would have different kind of output and what the user manipulates.

The cache works with a primary key (for the first implemented cache, the key is the

module version identifier) and will invalidate the results based on the cache policy

(should refresh modules).

The persistent cache uses the snapshot as the key in the store. In theory, should we

consider that we have a nearly perfect hash function, we could instead use the hash

of the snapshot as the key. Measurements would have to be made to check if it's worth

implementing.

  1. … 46 more files in changeset.
Extract common InstantiatingAction type

    • -0
    • +47
    ./InstantiatingAction.java
  1. … 2 more files in changeset.
Extract common InstantiatingAction type

    • -0
    • +47
    ./InstantiatingAction.java
  1. … 2 more files in changeset.