Re: JUnit 4.12-beta-1 is released

Hello

I am sorry for trashing the party but I have a couple of concerns that are very likely to slow down the adoption of JUnit-4.12 among the providers of 3rd-party tools ...

 --- 1) Don't remove JUnit4ClassRunner! (in package org.junit.internal.runners)

I have developed a number of 3rd-party runnners myself and I want the JUnit community to know that as a 3rd-party runner developer you want the latest version of your runner to work with any version of JUnit! - Otherwise the end-users (test-developers) will be less likely to start using your runner because they probably don't want to deal with the version-conflict hell that might raise between JUnit and your 3rd-party runner.

A couple of good examples are the 3rd-party runners MockitoJUnitRunner (from Mockito - http://mockito.org) and CallbackParamsRunner (from CallbackParams - http://callbackparams.org)

Both runner implementations extends JUnits Runner base-class. They both work as thin wrappers that hand over the main part of the test-execution to whichever JUnit-runner is appropriate for the JUnit-version on classpath, while they stay in the background ensuring that their intended features are magically appended on the test-execution with whichever extension points are appropriate for the JUnit-version at hand.

In this manner the runners will work with JUnit-4.4 (or even older versions) but they will also work fine with later JUnit-versions, therewith allowing their end-users to upgrade JUnit separatly in order to also benefit from new JUnit-features (such as JUnit-rules etc).

Now I do think that both of these runners will run just fine with JUnit-4.12-beta-1 but their builds would fail the day they decide to upgrade their JUnit dependency (e.g. if they want to leverage from some new JUnit feature in 4.12). - So in the end this will slow down the adoption of 4.12 in these 3rd-party projects because an upgrade would force their communities to extra efforts in order to preserve their backward-compatibility to older JUnit-version (such as 4.4).

 --- 2) Please remove pull-request #625 from the release! (The annotation @RunListener.ThreadSafe)

I think this pull-request represents a very poor design choice that - at best - might help performance only for JUnit runners that executes their tests with concurrent threads. I would like to point out that most smaller unit-tests do not!! - but they still suffer from the same RunListener slowness that this issue is supposed to address ...

A much better solution that would be generally beneficial to all types of JUnit runners would be to offer RunListener implementors some sort of concurrency API that allows RunListener implementations to use assynchronous execution of the parts that might take a long time. - That way it would be possible for all runners to seamlessly benefit from RunListeners that have clever assynchronous concurrency features!!

I can discuss this RunListener stuff forever but I don't really have the time - so I invite other clever people to join the discussion ...

---
BR /Henrik Kaipe