Hi. First of all, this is an incompatible change since the TestSubscriber is a public API and needs to maintain its method signatures. Second, varargs in Java 6 is problematic and we can't use the SafeVarargs annotation: the moment you try to assert an array of list of values, you get the unchecked warning.

@akarnokd, regarding the change incompatibility: I have only introduced new method with varargs, the method with list remains available, so should not break anything.
As for your second point: I see the problem with Java 6. Is compiler warning a blocker?

You're right, I've misread the diff page. The warning isn't a real blocker but we'd like to avoid much of it as possible.

As a matter of fact, I happen to have a PR in which the TestSubscriber is also expanded with lots of useful methods.

Regardless, I wouldn't have changed tests to use the new method since we usually don't look at test unless there is a problem with them. In that case or with new tests, the developers are free to use the more convenient methods.

@akarnokd I'm trying to figure out if this will cause any of the issues that made us move away from varargs in the past. You seem to have concluded that it won't?

Also I need to make sure the overload won't conflict with dynamic languages like Groovy and Clojure.

@Unisay Can you add the method without changing all the unit tests so this doesn't affect 30 files that don't need to be changed? Please rebase the change so it is a single commit just touching TestSubscriber.

I'm not sure about dynamic languages but I'd prefer a shorter assertValues(Object... values).

Handling in #2948 without changing the other 30 files.