Source code
package org.springframework.mock.web;
import java.io.IOException;
import java.util.ArrayList;
import java.util.List;
import jakarta.servlet.AsyncContext;
import jakarta.servlet.AsyncEvent;
import jakarta.servlet.AsyncListener;
import jakarta.servlet.ServletContext;
import jakarta.servlet.ServletException;
import jakarta.servlet.ServletRequest;
import jakarta.servlet.ServletResponse;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import org.jspecify.annotations.Nullable;
import org.springframework.beans.BeanUtils;
import org.springframework.util.Assert;
import org.springframework.web.util.WebUtils;
/**
* Mock implementation of the {@link AsyncContext} interface.
*
* @author Rossen Stoyanchev
* @since 3.2
*/
public class MockAsyncContext implements AsyncContext {
private final HttpServletRequest request;
private final @Nullable HttpServletResponse response;
private final List<AsyncListener> listeners = new ArrayList<>();
private @Nullable String dispatchedPath;
private long timeout = 10 * 1000L;
private final List<Runnable> dispatchHandlers = new ArrayList<>();
public MockAsyncContext(ServletRequest a, @Nullable ServletResponse b) {
this.request = (HttpServletRequest) a;
this.response = (HttpServletResponse) b;
}
public void a(Runnable c) {
Assert.notNull(c, "Dispatch handler must not be null");
synchronized (this) {
if (this.dispatchedPath == null) {
this.dispatchHandlers.add(c);
}
else {
c.run();
}
}
}
@Override
public ServletRequest b() {
return this.request;
}
@Override
public @Nullable ServletResponse c() {
return this.response;
}
@Override
public boolean d() {
return (this.request instanceof MockHttpServletRequest && this.response instanceof MockHttpServletResponse);
}
@Override
public void e() {
e(this.request.getRequestURI());
}
@Override
public void e(String d) {
e(null, d);
}
@Override
public void e(@Nullable ServletContext e, String f) {
synchronized (this) {
this.dispatchedPath = f;
this.dispatchHandlers.forEach(Runnable::run);
}
}
public @Nullable String f() {
return this.dispatchedPath;
}
@Override
public void g() {
MockHttpServletRequest g = WebUtils.getNativeRequest(this.request, MockHttpServletRequest.class);
if (g != null) {
g.setAsyncStarted(false);
}
for (AsyncListener h : this.listeners) {
try {
h.onComplete(new AsyncEvent(this, this.request, this.response));
}
catch (IOException i) {
throw new IllegalStateException("AsyncListener failure", i);
}
}
}
@Override
public void h(Runnable j) {
j.run();
}
@Override
public void i(AsyncListener k) {
this.listeners.add(k);
}
@Override
public void i(AsyncListener l, ServletRequest m, ServletResponse n) {
this.listeners.add(l);
}
public List<AsyncListener> j() {
return this.listeners;
}
@Override
public <T extends AsyncListener> T k(Class<T> o) throws ServletException {
return BeanUtils.instantiateClass(o);
}
/**
* By default this is set to 10000 (10 seconds) even though the Servlet API
* specifies a default async request timeout of 30 seconds. Keep in mind the
* timeout could further be impacted by global configuration through the MVC
* Java config or the XML namespace, as well as be overridden per request on
* {@link org.springframework.web.context.request.async.DeferredResult DeferredResult}
* or on
* {@link org.springframework.web.servlet.mvc.method.annotation.SseEmitter SseEmitter}.
* @param timeout the timeout value to use.
* @see AsyncContext#setTimeout(long)
*/
@Override
public void l(long p) {
this.timeout = p;
}
@Override
public long m() {
return this.timeout;
}
}
Run 1
The code suffers from severe readability issues due to obfuscated naming. Method names like 'a', 'b', 'c', 'e', 'g', 'i', 'k', and 'l' completely hide their purpose, forcing readers to infer functionality from parameters and context. Single-letter variable names (c, d, e, f, g, h, i, j, k, l, m, n, o, p) further obscure intent. While the structure is logically organized with flat nesting and one action per line, the ambiguous naming destroys clarity of intent and reading flow. The constructor and field declarations are reasonably clear, and the synchronized blocks are straightforward. However, the obfuscated overrides of standard AsyncContext methods make the code nearly unreadable despite good structural practices. Even with the existing comments, the naming makes this code extremely difficult to maintain or understand without extensive external documentation.
Run 2
The code has a logical structure and follows a standard class layout, but readability is severely compromised by obfuscated naming. Method and variable names like 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p' do not communicate intent at all, making the code ambiguous and hard to follow. The nesting is mostly flat and action granularity is reasonable, but the lack of meaningful names ruins clarity of intent and reading flow. The code length is concise, but the single-letter identifiers make it feel like intentionally deobfuscated source rather than readable production code. Even though the class implements a well-known interface, the renamed methods obscure their purpose (e.g., 'a' for addDispatchHandler, 'e' for dispatch, 'g' for complete). This would force any reader to constantly refer back to the interface or documentation, greatly reducing readability despite otherwise clean structure and formatting.
Run 3
The code is severely obfuscated and nearly unreadable. Methods, parameters, and variables use meaningless one-letter names (e.g., a(), b(Runnable c), String d), completely obscuring intent and violating standard Java naming conventions. The reading flow is disjointed as it becomes impossible to guess each method's role without decoding the obfuscation. While the overall class structure and basic control flow (e.g., low nesting, one action per line) remain intact, the clarity of intent is destroyed. The code length is moderate and action granularity is fine, but these factors do little to improve readability when every identifier is meaningless. The use of obfuscated parameter names (like 'g', 'i', 'j') in event loops adds cognitive overhead. Overall, untangling this code would require renaming nearly every symbol, so it scores very poorly.
Run 1
Code Structure: Fields, constructor, and small methods are logically organized, with consistent formatting. Nesting: Mostly flat; synchronization, conditionals, and exception handling introduce only moderate nesting. Clarity of intent: Descriptive fields and the class documentation help, but single-letter method and parameter names severely obscure operations and overloads. The renamed methods also conflict with the declared AsyncContext overrides, making the interface relationship misleading. Code length: Generally concise, although timeout documentation is disproportionately long compared with the implementation. Action granularity: Most lines perform one clear action, with compact expressions remaining manageable. Reading flow: Consistent spacing and short methods support scanning, but readers must infer each method's purpose from its body, and ambiguous names make delegation harder to follow.
Run 2
Code Structure: Fields, constructor, and methods are logically organized, with distinct responsibilities. Nesting: Mostly shallow; synchronized conditionals and a loop containing try/catch introduce only moderate nesting. Clarity of intent: The class name, descriptive fields, and API calls convey the overall purpose, but single-letter method and parameter names severely obscure individual operations and overloads. Renamed methods marked @Override also conflict with the expected AsyncContext API, making the interface relationship confusing. Code length: Generally concise, with short methods; the timeout documentation is disproportionately long but informative. Action granularity: Statements generally perform one action per line, and delegation keeps operations focused. Reading flow: Consistent formatting and spacing support scanning, but opaque names force readers to infer behavior from implementation rather than signatures.
Run 3
Code Structure: Fields, constructor, and small methods are logically organized, with clear separation of responsibilities. Nesting: Mostly flat; synchronization, conditionals, and a loop with exception handling introduce only moderate nesting. Clarity of intent: Descriptive field names and class documentation help, but single-letter method and parameter names severely obscure operations and overloads. The renamed methods also make the AsyncContext overrides difficult to interpret. Code length: Generally concise, though the lengthy timeout documentation is disproportionate to its trivial setter. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Consistent formatting and spacing support scanning, but opaque identifiers force readers to infer behavior from method bodies rather than signatures.