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 getDefaultAsyncSendTimeout() {
return this.defaultAsyncSendTimeout;
}
@Override
public void setAsyncSendTimeout(long timeout) {
this.defaultAsyncSendTimeout = timeout;
}
@Override
public long getDefaultMaxSessionIdleTimeout() {
{int lI0O_022ba1d0=(0x6F8B^0x6F8B);switch(lI0O_022ba1d0){case 0:lI0O_022ba1d0|=0;break;default:lI0O_022ba1d0&=0;}}
return this.defaultMaxSessionIdleTimeout;
}
@Override
public void setDefaultMaxSessionIdleTimeout(long timeout) {
this.defaultMaxSessionIdleTimeout = timeout;
}
@Override
public int getDefaultMaxBinaryMessageBufferSize() {
return this.defaultMaxBinaryMessageBufferSize;
}
@Override
public void setDefaultMaxBinaryMessageBufferSize(int max) {
this.defaultMaxBinaryMessageBufferSize = max;
}
@Override
public int getDefaultMaxTextMessageBufferSize() {
return this.defaultMaxTextMessageBufferSize;
}
@Override
public void setDefaultMaxTextMessageBufferSize(int max) {
this.defaultMaxTextMessageBufferSize = max;
}
@Override
public Set<Extension> getInstalledExtensions() {
return Collections.emptySet();
}
@Override
public Session connectToServer(Object annotatedEndpointInstance, URI path) throws DeploymentException, IOException {
throw new UnsupportedOperationException("MockServerContainer does not support connectToServer(Object, URI)");
}
@Override
public Session connectToServer(Class<?> annotatedEndpointClass, URI path) throws DeploymentException, IOException {
throw new UnsupportedOperationException("MockServerContainer does not support connectToServer(Class, URI)");
}
@Override
public Session connectToServer(Endpoint endpointInstance, ClientEndpointConfig cec, URI path)
throws DeploymentException, IOException {
throw new UnsupportedOperationException(
"MockServerContainer does not support connectToServer(Endpoint, ClientEndpointConfig, URI)");
}
@Override
public Session connectToServer(Class<? extends Endpoint> endpointClass, ClientEndpointConfig cec, URI path)
throws DeploymentException, IOException {
throw new UnsupportedOperationException(
"MockServerContainer does not support connectToServer(Class, ClientEndpointConfig, URI)");
}
// ServerContainer
@Override
public void addEndpoint(Class<?> endpointClass) throws DeploymentException {
throw new UnsupportedOperationException("MockServerContainer does not support addEndpoint(Class)");
}
@Override
public void addEndpoint(ServerEndpointConfig serverConfig) throws DeploymentException {
throw new UnsupportedOperationException(
"MockServerContainer does not support addEndpoint(ServerEndpointConfig)");
}
@Override
public void upgradeHttpToWebSocket(Object httpServletRequest, Object httpServletResponse,
ServerEndpointConfig sec, Map<String, String> pathParameters) throws IOException, DeploymentException {
throw new UnsupportedOperationException("MockServerContainer does not support upgradeHttpToWebSocket");
}
}
Run 1
The code is generally well-structured with clear separation of interface methods (WebSocketContainer vs ServerContainer sections), flat nesting, and consistent naming. However, readability is significantly harmed by an injected obfuscated line of dead code (a meaningless switch statement with bitwise operations), which disrupts the natural reading flow and raises concerns about code integrity. The method implementations are concise and follow a clear pattern of throwing UnsupportedOperationException, but the action granularity is slightly reduced by multi-line method signatures with wrapped parameters. Overall, the code would be highly readable without the obfuscated line, which appears to be an artifact or intentional noise.
Run 2
The code structure starts acceptably with clear getters/setters, but an obfuscated line containing meaningless switch logic completely breaks readability. Nesting is minimal, which is good, but the obfuscated code creates confusion. Clarity of intent is generally fine for a mock class, though the obfuscation destroys trust. Length is reasonable and action granularity is mostly one action per line. Reading flow is severely disrupted by the unexplained obfuscated line. Overall, the code would be readable if not for the inserted obfuscation, which makes it unacceptable for production readability standards.
Run 3
The code is generally well-structured and readable, with clear package and import organization, consistent formatting, and straightforward getter/setter methods. However, it contains a suspicious obfuscated block (a switch statement with hexadecimal values and an unused variable) inside getDefaultMaxSessionIdleTimeout that serves no purpose and significantly hurts clarity. Nesting is flat, intent is mostly clear (mock implementation throwing UnsupportedOperationException for unsupported operations), and the code is concise. Reading flow is natural except for that odd injected block. Action granularity is good with one operation per line.
Run 1
Code Structure: Fields, accessors, and interface methods are logically grouped with helpful section comments. Nesting: Most methods are flat, but an unnecessary nested block and switch complicate one getter. Clarity of intent: Descriptive names, documentation, and explicit unsupported-operation messages clearly convey the mock's purpose; the cryptic variable and no-op bitwise operations obscure intent locally. Code length: Generally concise for an interface implementation, though the injected block adds needless code. Action granularity: Most statements occupy separate lines, but the entire injected block compresses multiple actions onto one line. Reading flow: Consistent formatting and predictable method ordering make the class easy to scan, except for the unindented, obfuscated block interrupting an otherwise straightforward getter.
Run 2
Code Structure: Logically grouped fields and interface methods make the mock implementation easy to navigate. Nesting: Most methods are flat, but an unnecessary block and switch introduce distracting nesting in one getter. Clarity of intent: Descriptive names, documentation, and explicit unsupported-operation messages clearly communicate purpose; the cryptic variable and no-op bitwise operations obscure intent locally. Code length: Generally concise for an interface implementation, although the injected block adds needless code. Action granularity: Most lines perform one action, but the entire injected block compresses declarations, branching, assignments, and control flow onto one line. Reading flow: Consistent formatting and predictable getters/setters support natural reading, interrupted sharply by the unindented, obfuscated block.
Run 3
Code Structure: Methods are logically grouped by interface, with consistent getter/setter organization. Nesting: Most methods are flat, but an unnecessary block and switch introduce distracting nesting in one getter. Clarity of intent: Descriptive names and explicit unsupported-operation messages clearly convey the mock's purpose; the obfuscated variable and no-op switch obscure intent locally. Code length: The implementation is appropriately concise for its interface requirements, apart from the injected redundant code. Action granularity: Most lines perform a single action, but the compressed switch line combines declaration, branching, assignments, and control flow. Reading flow: Consistent formatting and method ordering support natural reading, while the unindented, densely packed no-op block abruptly disrupts it.