Source code
package org.junit.runner.notification;
import org.junit.runner.Description;
import org.junit.runner.Result;
/**
* Thread-safe decorator for {@link RunListener} implementations that synchronizes
* calls to the delegate.
*
* <p>This class synchronizes all listener calls on a RunNotifier instance. This is done because
* prior to JUnit 4.12, all listeners were called in a synchronized block in RunNotifier,
* so no two listeners were ever called concurrently. If we instead made the methods here
* sychronized, clients that added multiple listeners that called common code might see
* issues due to the reduced synchronization.
*
* @author Tibor Digana (tibor17)
* @author Kevin Cooney (kcooney)
* @since 4.12
*
* @see RunNotifier
*/
@RunListener.ThreadSafe
final class SynchronizedRunListener extends RunListener {
private final RunListener fListener;
private final Object fMonitor;
SynchronizedRunListener(RunListener listener, Object monitor) {
fListener = listener;
fMonitor = monitor;
}
@Override
public void testRunStarted(Description description) throws Exception {
synchronized (fMonitor) {
fListener.testRunStarted(description);
}
}
@Override
public void testRunFinished(Result result) throws Exception {
synchronized (fMonitor) {
fListener.testRunFinished(result);
}
}
@Override
public void testStarted(Description description) throws Exception {
synchronized (fMonitor) {
fListener.testStarted(description);
}
}
@Override
public void testFinished(Description description) throws Exception {
synchronized (fMonitor) {
fListener.testFinished(description);
}
}
@Override
public void testFailure(Failure failure) throws Exception {
synchronized (fMonitor) {
fListener.testFailure(failure);
}
}
@Override
public void testAssumptionFailure(Failure failure) {
synchronized (fMonitor) {
fListener.testAssumptionFailure(failure);
}
}
@Override
public void testIgnored(Description description) throws Exception {
synchronized (fMonitor) {
fListener.testIgnored(description);
}
}
@Override
public int hashCode() {
return fListener.hashCode();
}
@Override
public boolean equals(Object other) {
if (this == other) {
return true;
}
if (!(other instanceof SynchronizedRunListener)) {
return false;
}
SynchronizedRunListener that = (SynchronizedRunListener) other;
return fListener.equals(that.fListener);
}
@Override
public String toString() {
return fListener.toString() + " (with synchronization wrapper)";
}
}
Run 1
The code exhibits excellent readability. Its structure is logical: a single class with a clear purpose, documented well. Nesting is minimal, with one level of synchronized blocks and straightforward conditionals. Intent is clear from the class name, Javadoc, and method names. The code is concise, avoiding unnecessary verbosity while maintaining readability. Each method performs a single action, and the synchronized blocks have a single delegate call per line. Reading flow is natural, following a consistent pattern across lifecycle methods. Minor deductions for the legacy 'f' prefix on fields and the slightly verbose Javadoc, but overall it is highly readable.
Run 2
The code is highly readable. It follows a clear, consistent structure: each overridden method simply synchronizes on a monitor and delegates to the wrapped listener. Nesting is minimal—only one level of synchronized blocks. The class and method purposes are evident from the Javadoc and naming. Code length is concise; each method is only a few lines, with one action per line. Reading flow is natural, with methods logically grouped. Minor deductions: a typo in the Javadoc ('sychronized') and slightly verbose equals method, but overall this is exemplary for a decorator pattern.
Run 3
The code is highly readable. Structure is logical, with a clear decorator pattern and consistent organization of overridden methods. Nesting is flat: each method contains only a single synchronized block. Intent is explicit through class name, Javadoc, and method naming. Code length is appropriate—each delegation is concise and avoids unnecessary abstraction. Action granularity respects one action per line: delegation happens inside a clearly scoped synchronized block. Reading flow is natural, grouping listener callbacks, then standard Object method overrides. Minor deductions: repeated synchronized/delegate boilerplate could be reduced with a helper, and the Javadoc has a minor typo ('sychronized'), but these do not materially affect comprehension.
Run 1
Code Structure: Fields, constructor, listener callbacks, and object overrides are logically grouped. Nesting: Each callback has only one synchronization block, and equals uses clear early returns. Clarity of intent: The class name, annotation, and documentation clearly explain the decorator and shared-monitor rationale; the f-prefixed field names are slightly less natural. Code length: Repeated callback wrappers add length but are straightforward and justified by the interface. Action granularity: Each statement performs a single action, making delegation and synchronization easy to follow. Reading flow: Consistent formatting and predictable method patterns support smooth reading. Minor drawbacks are repetitive boilerplate and a documentation typo.
Run 2
Code Structure: Fields, constructor, listener callbacks, and utility overrides are logically grouped. Nesting: Each callback has only one synchronization block, and equals uses straightforward early returns. Clarity of intent: The class name, method names, and documentation clearly explain the synchronization decorator and its rationale; the f-prefixed fields are slightly dated but understandable. Code length: Repeated callback wrappers add length, but the repetition is necessary and makes behavior explicit. Action granularity: Each statement performs a single clear action, with no compressed logic. Reading flow: Consistent formatting and predictable delegation make the class easy to scan from initialization through callbacks to equality and string representation. Minor documentation imperfections, including a typo and describing the generic monitor as a RunNotifier instance, slightly reduce polish.
Run 3
Code Structure: Logically organized into fields, constructor, listener callbacks, and object-method overrides. Nesting: Shallow, with only a single synchronization block per callback and simple guard clauses in equals. Clarity of intent: The class name, descriptive method names, and documentation clearly explain the synchronized decorator and its shared-monitor rationale; the legacy f-prefix field names are slightly less natural. Code length: Concise overall; repeated callback wrappers add length but make synchronization explicit and consistent. Action granularity: Each statement performs one clear action, with delegation and synchronization visibly separated. Reading flow: Consistent formatting and predictable method patterns make the code easy to scan from initialization through event handling to equality and representation.