Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Use a consistent chain of exceptions on failure to create an instance of the action implementation, for worker actions, artifact transforms, attribute compatibility rules, attribute disambiguation rules and metadata supplier rules.

  1. … 7 more files in changeset.
Replace `TypeToken<T>` by `ModelType<T>` in `TypeOf<T>`

And introduce `TypeOf.Visitor`.

  1. … 6 more files in changeset.
Add coverage for Types.getGenericSimpleName(Type)

And fix basic wildcard type case, e.g. List<?>

  1. … 1 more file in changeset.
Allow extension public types to be specified via “type token”

and by being so, faithfully represent generic types.

  1. … 9 more files in changeset.
Avoid usage of `EqualsBuilder`

Calling `getGenericParameterTypes` is very expensive, and usage of `EqualsBuilder` implies calling the methods

even if they shouldn't be. This reworks the algorithm to avoid use of equals builder, and also changes the

generated hash code to use parameter types instead of generic parameter types.

This shaves a few ms for cold daemon startup (first use case, or `--no-daemon`).

Remove logging as it doesn't bring much value and log4j is not always available

There was an error in `buildSrc` compilation for some performance tests due to missing log4j dependency.

Signed-off-by: Cedric Champeau <>

Avoid the creation of a `Factory<T>` for each call to `get`

Rework the reflection cache

The reflection cache is now safer, because we use a hierarchical cache where

the node entries are weakly referenced `Class` instances. Typically the first

level of the cache would be the receiver, while lower levels would be the

argument types. If those types are collected, the weak hash maps that we use

internally would automatically clean the entries. Eventually, the value associated

with this "path" of `Class` itself references a `Method` or a `Constructor`

with additional, computed, data.

The advantage of this approach is that typically for the instantiator case,

we no longer need to match the argument types (`isMatch`) for each call: instead,

we go through the tree using subsequent argument types, and if a match is found,

we know it's the right one.

  1. … 4 more files in changeset.
Attempt to implement faster `stat` using JDK 7 attributes

  1. … 6 more files in changeset.
Reuse the same infrastructure for cached constructors and cached methods

  1. … 2 more files in changeset.
Fix GC possibly collecting cached entries when using only weak references: values need to be validated

  1. … 1 more file in changeset.
Do not wrap values in `WeakReference`

It's not the cache which should wrap values into weak references, but the value itself that should

do whatever is necessary to avoid the `Class` from being un-collectable.

Small optimization : wrapped types need not be wrapped into weak references since they will never be collected

Fix unit test

  1. … 1 more file in changeset.
Re-use the same infrastructure for `DirectInstantiator` and `MapNotationConverter` caches

This makes the cache in `MapNotationConverter` thread-safe. It's not yet externalized though.

    • -0
    • +50
  1. … 1 more file in changeset.
Make `CachedConstructor` safer by wrapping parameter types in `WeakReferences`

Impact on performance is yet to be checked...

Fix initial match not found in service registry candidate list

  1. … 1 more file in changeset.
Slightly optimize `DirectInstantiator`

This commit reworks the direct instantiator cache, by avoiding to recompute the parameter types of the

constructor each time, as well as wrapped parameter types. The reason is that `getParameterTypes` clones

the underlying parameter type array, which creates garbage immediately collected, for each constructor

we test, for each instantiation.

  1. … 1 more file in changeset.
Remove unnecessary parameter

+review REVIEW-6090

  1. … 5 more files in changeset.
Move type hierarchy walker to `base-services`

We'll need it in other places, too.

+review REVIEW-5989

  1. … 6 more files in changeset.
Move `PropertyAccessorType` to `base-services`

    • -0
    • +149
  1. … 18 more files in changeset.
Add a cache for `propertyExists` because it is intensively called from `ConventionAwareHelper`

  1. … 1 more file in changeset.
Avoid relying on exceptions to find reflective information like `getField`

Those methods are called a number of time in the Gradle build itself and cause a lot of exceptions to be thrown and caught for nothing.

Replace usage of `String#format` with good old string concatenation

The rationale behind this change is that while `String#format` is usually admitted as good for readability (this is arguable),

in practice it is very bad for performance. Since Java 6, the JVM (the JIT, to be correct) does a pretty good job at optimizing

string concatenation. However, it is only capable to do so if we're using "dirty" string concatenations (using `+`), or `StringBuilder`.

However, usage of `StringBuilder` is not recommended either for 2 reasons:

1. it significantly decreases code readability

2. in Java 9, String concatenation is even more optimized thanks to `invokedynamic`, and code using `StringBuilder` will *not* benefit

from this optimization.

There are sill leftover `String#format` calls in the code, in the following cases:

- the call is used to generate an exception message. That's 90% of the remaining calls.

- the call is obviously a debug message, often used in `toString` (because as we all know, `toString` should only be used for debugging)

- the format includes specific number formatting patterns

- I missed it

  1. … 226 more files in changeset.
Fix regression in error reporting

+review REVIEW-5921

Optimize `DirectInstantiator`

* remove the use of an intermediate `ArrayList` to build the result

* cache `getConstructors` call

* add JMH benchmark to prove that caching is faster

+review REVIEW-5921

  1. … 3 more files in changeset.
Rework setting of project properties to avoid dynamic calls altogether

  1. … 5 more files in changeset.
`coll.toArray(new T[coll.size()])` => `coll.toArray(new T[0])`

> Bottom line: toArray(new T[0]) seems faster, safer, and contractually cleaner, and therefore should be the default choice now. Future VM optimizations may close this performance gap for toArray(new T[size]), rendering the current "believed to be optimal" usages on par with an actually optimal one. Further improvements in toArray APIs would follow the same logic as toArray(new T[0]) — the collection itself should create the appropriate storage.

Let's see what our performance tests say, if this is noticeable at all.

Changes made by IDEA "Structural Replace":

$coll$.toArray(new $T$[$coll$.size()])


$coll$.toArray(new $T$[0])

+review REVIEW

  1. … 38 more files in changeset.
Use struct binding information when generating proxies

Use the pre-calculated method bindings to generate view proxies. With

this change some logic has been moved out from the proxy generator,

making it simpler.

It is now possible for the validation of extensible types (which is now

spread between instantiation, type registration and schema extraction)

to happen mostly in one place, where we have all the required context.

This change also opens up the possibility to remove `@Managed` as a

concept, and handle all view types the same way.

+review REVIEW-5761

  1. … 25 more files in changeset.
Include some more context in exceptions thrown when the value provided for a scalar typed property cannot be converted to the target type.

In particular, include the name of the property and the value that was provided.

    • -0
    • +29
  1. … 3 more files in changeset.