Description

There is a number of methods in EQL's fluent API that have variable arity.

For example:

T allOfValues(final Object... values);

Often the source of argument values to such methods is a Collection, which results in the
following pattern being employed:

Set<Object> ourValues = ...;
... .allOfValues(ourValues.toArray()) ...

It would be beneficial for programming ergonomics to have such methods accept Collection instances directly.

Expected outcome

Fluent API methods are enhanced with additional signatures that accept instances of Collection.

Implementation details

Consider the existence of the following methods in the same class:

// (1)
public void accept(Object... values) {}

// (2)
public void accept(Collection<?> values) {}

Given accept(List.of()), it might at first seem unclear which method is going to be called: both are applicable.

According to the JLS, (2) is more specific, thus it is the one that will be called, which is fitting for the use case of this issue.