Source code
package org.springframework.test.context.web.socket;
import java.io.IOException;
import java.net.URI;
import java.util.Collections;
import java.util.Map;
import java.util.Set;
import jakarta.websocket.ClientEndpointConfig;
import jakarta.websocket.DeploymentException;
import jakarta.websocket.Endpoint;
import jakarta.websocket.Extension;
import jakarta.websocket.Session;
import jakarta.websocket.server.ServerContainer;
import jakarta.websocket.server.ServerEndpointConfig;
/**
* Mock implementation of the {@link jakarta.websocket.server.ServerContainer} interface.
*
* @author Sam Brannen
* @since 4.3.1
*/
class MockServerContainer implements ServerContainer {
private long defaultAsyncSendTimeout;
private long defaultMaxSessionIdleTimeout;
private int defaultMaxBinaryMessageBufferSize;
private int defaultMaxTextMessageBufferSize;
// WebSocketContainer
@Override
public long get() {
return this.defaultAsyncSendTimeout;
}
@Override
public void set(long tim) {
this.defaultAsyncSendTimeout = tim;
}
@Override
public long get2() {
return this.defaultMaxSessionIdleTimeout;
}
@Override
public void set2(long tim2) {
this.defaultMaxSessionIdleTimeout = tim2;
}
@Override
public int get3() {
return this.defaultMaxBinaryMessageBufferSize;
}
@Override
public void set3(int max) {
this.defaultMaxBinaryMessageBufferSize = max;
}
@Override
public int get4() {
return this.defaultMaxTextMessageBufferSize;
}
@Override
public void set4(int max) {
this.defaultMaxTextMessageBufferSize = max;
}
@Override
public Set<Extension> get5() {
return Collections.emptySet();
}
@Override
public Session connect(Object annotated, URI pat) throws DeploymentException, IOException {
throw new UnsupportedOperationException("MockServerContainer does not support connectToServer(Object, URI)");
}
@Override
public Session connect(Class<?> annotated2, URI pat2) throws DeploymentException, IOException {
throw new UnsupportedOperationException("MockServerContainer does not support connectToServer(Class, URI)");
}
@Override
public Session connect(Endpoint endpoint, ClientEndpointConfig cec, URI pat3)
throws DeploymentException, IOException {
throw new UnsupportedOperationException(
"MockServerContainer does not support connectToServer(Endpoint, ClientEndpointConfig, URI)");
}
@Override
public Session connect(Class<? extends Endpoint> endpoint2, ClientEndpointConfig cec, URI pat4)
throws DeploymentException, IOException {
throw new UnsupportedOperationException(
"MockServerContainer does not support connectToServer(Class, ClientEndpointConfig, URI)");
}
// ServerContainer
@Override
public void add(Class<?> endpoint3) throws DeploymentException {
throw new UnsupportedOperationException("MockServerContainer does not support addEndpoint(Class)");
}
@Override
public void add(ServerEndpointConfig server2) throws DeploymentException {
throw new UnsupportedOperationException(
"MockServerContainer does not support addEndpoint(ServerEndpointConfig)");
}
@Override
public void upgrade(Object http, Object http2,
ServerEndpointConfig sec, Map<String, String> path) throws IOException, DeploymentException {
throw new UnsupportedOperationException("MockServerContainer does not support upgradeHttpToWebSocket");
}
}
Run 1
The code is a mock implementation with a clear purpose, but readability is severely undermined by poor naming. Methods are named get(), set(), get2(), set2(), get3(), set3(), get4(), set4(), and get5(), which completely obscure their intent — presumably they correspond to interface methods like getDefaultAsyncSendTimeout, but the names have been replaced with meaningless suffixes. Parameters like `tim`, `tim2`, `pat`, `cec`, `http`, and `http2` are equally cryptic. The class structure is logically organized (WebSocketContainer methods first, then ServerContainer), and the unsupported-operation methods follow a consistent pattern, which helps. Nesting is minimal and action granularity is acceptable. However, the bad naming destroys clarity and reading flow, requiring readers to guess or consult the interface constantly. Code length is reasonable for a mock, but the confusing identifiers make it feel longer than it is. Overall, the structure keeps it from being unreadable, but the naming choices significantly reduce comprehension.
Run 2
The code is poorly readable. Method names like get(), get2(), get3(), set3(), get5(), connect(), add() are meaningless and hide the actual interface methods they override (e.g., getDefaultAsyncSendTimeout). Parameter names like 'tim', 'tim2', 'pat', 'pat2', 'cec', 'sec', 'endpoint2', 'annotated2' are obscure and fail to convey intent. Structure is flat but repetitive, with many one-line UnsupportedOperationException throws causing unnecessary length. Action granularity is adequate, but reading flow suffers from nonsensical method and parameter naming. Nesting is low, which is one of few positives. Overall, the code is functional but extremely ambiguous and difficult to understand without external context.
Run 3
The code has reasonable class structure with clear sections for WebSocketContainer and ServerContainer, but readability is severely undermined by several issues. Method names like get(), set(), get2(), set2(), get3() are meaningless and obscure intent, making it difficult to understand what each method actually configures. Parameter names like 'tim', 'tim2', 'pat', 'pat2', 'pat3', 'pat4', 'endpoint2', 'endpoint3' are non-descriptive, further hampering comprehension. The action granularity is mostly acceptable with one operation per line, and the nesting is flat, but the reading flow is disrupted by the confusing naming conventions. The code appears to be a mock implementation where original method names have been stripped away, possibly through obfuscation or poor refactoring. While the length is concise and structure is logical, the lack of meaningful identifiers makes this code difficult to maintain and understand without external documentation.
Run 1
Code Structure: Fields and methods are logically organized, with comments separating container responsibilities. Nesting: Methods are flat and contain no nested control flow. Clarity of intent: The class documentation, descriptive fields, and exception messages establish its mock purpose, but generic names such as get2, set3, pat4, and http2 obscure individual method and parameter meanings. Code length: Methods are short; repeated unsupported-operation exceptions add predictable boilerplate rather than substantial complexity. Action granularity: Each statement performs a single action, making execution easy to follow. Reading flow: Consistent formatting and straightforward getter/setter pairs support scanning, although excessive blank lines and numbered identifiers interrupt comprehension and require readers to inspect method bodies.
Run 2
Code Structure: Fields and methods are logically grouped, with comments separating container responsibilities. Nesting: Methods are flat and contain no complex control flow. Clarity of intent: The class documentation, descriptive fields, and exception messages communicate its mock purpose, but names such as get2, set3, pat4, and http2 obscure individual method and parameter meanings. Code length: Reasonably concise for a mock implementation, though repetitive accessors and exception boilerplate add length. Action granularity: Each statement performs a single action, making method bodies easy to scan. Reading flow: Consistent formatting and predictable method patterns support navigation, but numbered names force readers to inspect bodies to understand behavior, and exception messages reference names different from the declared methods.
Run 3
Code Structure: Fields and methods are logically organized, with comments separating container responsibilities. Nesting: All methods are flat and simple, making control flow easy to follow. Clarity of intent: Descriptive fields and exception messages explain the mock's behavior, but numbered method names such as get2/set3 and vague parameters such as pat4/http2 obscure purpose. Code length: Reasonably concise for a mock implementation, though repeated unsupported-operation methods add boilerplate. Action granularity: Each line generally performs one action, with straightforward assignments, returns, and throws. Reading flow: Consistent formatting and predictable method patterns support scanning, but readers must inspect method bodies or exception messages to understand ambiguously named methods.