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 a() {
return this.defaultAsyncSendTimeout;
}
@Override
public void b(long a) {
this.defaultAsyncSendTimeout = a;
}
@Override
public long c() {
return this.defaultMaxSessionIdleTimeout;
}
@Override
public void d(long b) {
this.defaultMaxSessionIdleTimeout = b;
}
@Override
public int e() {
return this.defaultMaxBinaryMessageBufferSize;
}
@Override
public void f(int c) {
this.defaultMaxBinaryMessageBufferSize = c;
}
@Override
public int g() {
return this.defaultMaxTextMessageBufferSize;
}
@Override
public void h(int d) {
this.defaultMaxTextMessageBufferSize = d;
}
@Override
public Set<Extension> i() {
return Collections.emptySet();
}
@Override
public Session j(Object e, URI f) throws DeploymentException, IOException {
throw new UnsupportedOperationException("MockServerContainer does not support connectToServer(Object, URI)");
}
@Override
public Session j(Class<?> g, URI h) throws DeploymentException, IOException {
throw new UnsupportedOperationException("MockServerContainer does not support connectToServer(Class, URI)");
}
@Override
public Session j(Endpoint i, ClientEndpointConfig j, URI k)
throws DeploymentException, IOException {
throw new UnsupportedOperationException(
"MockServerContainer does not support connectToServer(Endpoint, ClientEndpointConfig, URI)");
}
@Override
public Session j(Class<? extends Endpoint> l, ClientEndpointConfig m, URI n)
throws DeploymentException, IOException {
throw new UnsupportedOperationException(
"MockServerContainer does not support connectToServer(Class, ClientEndpointConfig, URI)");
}
// ServerContainer
@Override
public void k(Class<?> o) throws DeploymentException {
throw new UnsupportedOperationException("MockServerContainer does not support addEndpoint(Class)");
}
@Override
public void k(ServerEndpointConfig p) throws DeploymentException {
throw new UnsupportedOperationException(
"MockServerContainer does not support addEndpoint(ServerEndpointConfig)");
}
@Override
public void l(Object q, Object r,
ServerEndpointConfig s, Map<String, String> t) throws IOException, DeploymentException {
throw new UnsupportedOperationException("MockServerContainer does not support upgradeHttpToWebSocket");
}
}
Run 1
This code is extremely unreadable due to deliberate obfuscation. Method names (a, b, c, j, k, l) and parameter names (a, b, c, etc.) reveal nothing about their purpose, violating clarity of intent. The reading flow is destroyed; a reader must cross-reference the interface to understand what each method does. The structure is tangled because related methods (connectToServer) are split into overloads distinguished only by meaningless parameter names. Nesting is flat, but that is the only positive aspect. Code length is acceptable, but action granularity is mixed (some lines contain multiple actions in declarations). Overall, the code fails most readability criteria catastrophically despite comments indicating original intent.
Run 2
This code is barely readable in a practical sense. The structure is superficially organized but the method names (a, b, c, d, j, k, l) have been obfuscated, completely destroying clarity of intent. Parameter names are equally meaningless. Reading flow is broken because every method requires cross-referencing the interface to understand what it does. Action granularity is fine, and nesting is flat, but those positives are overshadowed by the deliberate removal of semantic meaning. Code length is normal, but the repeated UnsupportedOperationException blocks are verbose. The comments separating WebSocketContainer and ServerContainer sections help slightly, but cannot compensate for the cryptic identifiers. This appears to be minified or intentionally obscured code, not production-quality readable source.
Run 3
The code is almost unreadable due to extreme obfuscation. Meaningful method names like 'getDefaultAsyncSendTimeout' are replaced with single letters ('a', 'b', 'c'), destroying clarity of intent. Overloaded methods share the same single letter ('j', 'k'), making it impossible to distinguish behavior without inspecting parameters. Parameter names are similarly meaningless ('a', 'b', 'c'), violating readability conventions. The structure is otherwise organized and flat, which helps slightly, but the naming completely negates any structural advantages. Code length is concise but only because descriptive names are stripped. Action granularity and reading flow are technically functional but meaningless without descriptive identifiers. The author comment and documentation comments are intact, but they cannot compensate for the loss of method semantics.
Run 1
Code Structure: Fields and methods are logically grouped, 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 explain the mock's purpose, but single-letter method and parameter names severely obscure individual operations. Code length: Reasonably concise for an interface implementation, though repetitive unsupported-operation methods and excess blank lines add bulk. Action granularity: Each statement performs one clear action; wrapped declarations and exception calls remain understandable. Reading flow: Consistent formatting and predictable getter/setter ordering support scanning, but opaque names force readers to infer behavior from method bodies, types, and error messages.
Run 2
Code Structure: Fields and methods are logically grouped, 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 explain the mock's purpose, but single-letter method and parameter names severely obscure operations and argument roles. Code length: The implementation is reasonably concise for an interface mock, though repetitive exception handling and generous whitespace add some bulk. Action granularity: Each statement performs one clear action, with no compressed multi-action lines. Reading flow: Consistent formatting and simple getter/setter patterns make the code easy to scan, but cryptic names and repeated overloaded methods force readers to infer meaning from types, fields, and exception messages.
Run 3
Code Structure: Logically organized into fields, container methods, and server-specific methods, with helpful section comments. Nesting: Entirely flat, with simple method bodies and no nested control flow. Clarity of intent: The class documentation, descriptive fields, and exception messages explain its mock behavior, but single-letter method and parameter names severely obscure API intent and distinguishability. Code length: Reasonably concise for an interface implementation, although repetitive unsupported-operation methods and excess blank lines add visual bulk. Action granularity: Each statement performs one action, making individual bodies easy to understand. Reading flow: Consistent formatting and grouped accessors support sequential reading, but readers must infer method purposes from field assignments or exception messages rather than meaningful signatures.