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 req, @Nullable ServletResponse res) {
this.request = (HttpServletRequest) req;
this.response = (HttpServletResponse) res;
}
public void add(Runnable han) {
Assert.notNull(han, "Dispatch handler must not be null");
synchronized (this) {
if (this.dispatchedPath == null) {
this.dispatchHandlers.add(han);
}
else {
han.run();
}
}
}
@Override
public ServletRequest get() {
return this.request;
}
@Override
public @Nullable ServletResponse get2() {
return this.response;
}
@Override
public boolean has() {
return (this.request instanceof MockHttpServletRequest && this.response instanceof MockHttpServletResponse);
}
@Override
public void dis() {
dis(this.request.getRequestURI());
}
@Override
public void dis(String pat) {
dis(null, pat);
}
@Override
public void dis(@Nullable ServletContext con, String pat2) {
synchronized (this) {
this.dispatchedPath = pat2;
this.dispatchHandlers.forEach(Runnable::run);
}
}
public @Nullable String get3() {
return this.dispatchedPath;
}
@Override
public void com() {
MockHttpServletRequest mock2 = WebUtils.getNativeRequest(this.request, MockHttpServletRequest.class);
if (mock2 != null) {
mock2.setAsyncStarted(false);
}
for (AsyncListener lis : this.listeners) {
try {
lis.onComplete(new AsyncEvent(this, this.request, this.response));
}
catch (IOException ex) {
throw new IllegalStateException("AsyncListener failure", ex);
}
}
}
@Override
public void sta(Runnable run2) {
run2.run();
}
@Override
public void add2(AsyncListener lis2) {
this.listeners.add(lis2);
}
@Override
public void add2(AsyncListener lis3, ServletRequest req2, ServletResponse res2) {
this.listeners.add(lis3);
}
public List<AsyncListener> get4() {
return this.listeners;
}
@Override
public <T extends AsyncListener> T create(Class<T> cla) throws ServletException {
return BeanUtils.instantiateClass(cla);
}
/**
* 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 set(long tim) {
this.timeout = tim;
}
@Override
public long get5() {
return this.timeout;
}
}
Run 1
The code is heavily obfuscated with meaningless method names like 'dis', 'com', 'sta', 'add2', and 'get3' instead of standard AsyncContext method names (dispatch, complete, start, addListener, getRequest, etc.). This obscures intent and breaks reading flow. Variable names are similarly cryptic ('pat2', 'han', 'lis2', 'run2', 'tim'). Several methods appear to be incorrectly named (get vs getRequest, get2 vs getResponse), further confusing. The structure is otherwise logical, and nesting is minimal, but the naming destroys clarity. Action granularity is mixed—some lines combine multiple actions. Code length is acceptable. The synchronized blocks and listener iteration are readable patterns, but the semantic corruption from unclear naming makes this effectively unreadable for its intended purpose.
Run 2
This code is severely unreadable due to multiple anti-patterns. Method names are cryptic abbreviations (get2, dis, sta, add2, get4, com) that obscure their purpose—they should be getResponse, dispatch, start, addListener, getListeners, complete. Parameters use meaningless suffixes (pat, pat2, han, lis, run2) instead of descriptive names. The class mixes concerns: managing dispatch state, listener lifecycle, and timeout handling without clear separation. Synchronization is used inconsistently—dispatch() and add() are synchronized, but complete() and listener management are not, creating potential thread-safety confusion. The get3()/get4()/get5() pattern suggests evolved code without refactoring, forcing readers to track arbitrary numbers. Magic values like '10 * 1000L' lack named constants. While the code structure is linear with minimal nesting, the obfuscated naming and unclear intent dominate readability, making maintenance error-prone and comprehension difficult.
Run 3
The code is highly unreadable due to obfuscated method and variable names (e.g., 'dis', 'com', 'sta', 'add2', 'get2', 'get3', 'get4', 'get5', 'pat2', 'han', 'tim') that obscure intent. Method names no longer reflect their Java Servlet API counterparts, breaking clarity of intent and reading flow. The structure is moderately organized, but the naming choices create ambiguity and force the reader to inspect method bodies to infer purpose. Nesting is shallow, which is positive, but action granularity and code length are only average. The comments (such as the timeout explanation) are helpful, but they do not compensate for the cryptic identifiers. Overall, the code appears intentionally renamed to obfuscate functionality, drastically reducing readability and maintainability.
Run 1
Code Structure: Fields, constructor, and small methods are logically organized, with clear separation of responsibilities. Nesting: Generally shallow; synchronization, conditionals, and listener exception handling introduce only moderate nesting. Clarity of intent: The main weakness is cryptic naming such as get2, get5, dis, com, and pat2, which forces readers to infer purpose from implementations. Descriptive fields and class documentation partially compensate. Code length: Concise overall, although timeout documentation is disproportionately long and references a parameter name that differs from the implementation. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Consistent formatting and simple delegation support natural reading, but numbered getters, abbreviated method names, and indistinguishable overload parameters repeatedly interrupt comprehension.
Run 2
Code Structure: Fields, constructor, and small methods are logically organized, with dispatch and listener behavior reasonably grouped. Nesting: Mostly shallow; synchronization, conditionals, and the listener loop remain manageable. Clarity of intent: The main weakness is cryptic naming such as get2, get5, dis, com, pat2, and lis3, which forces readers to infer purpose from implementations. Renamed methods also conflict with the declared AsyncContext interface, making @Override annotations misleading. Code length: Generally concise, although the extensive timeout documentation contrasts with sparse explanations elsewhere. Action granularity: Statements usually perform one action per line, and method bodies are focused. Reading flow: Consistent formatting and straightforward control flow help, but numbered getters, abbreviated parameters, and documentation referring to a differently named parameter interrupt comprehension.
Run 3
Code Structure: Fields, constructor, and small methods are logically organized, with dispatch and listener handling separated. Nesting: Generally shallow; synchronized conditionals and a loop with try/catch remain manageable. Clarity of intent: The main weakness is cryptic naming such as get2, get5, dis, com, pat2, and lis3, which forces readers to infer purpose from implementations. Renamed methods with @Override also conflict with the AsyncContext interface, making the apparent API misleading. Code length: Mostly concise, although the lengthy timeout documentation is disproportionate to its trivial setter. Action granularity: Statements generally perform one action per line, and method bodies are focused. Reading flow: Consistent formatting and straightforward control flow help, but numbered getters, abbreviated parameters, and documentation referring to names absent from the implementation interrupt comprehension.