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;
class MockServerContainer implements ServerContainer {
private long defaultAsyncSendTimeout;
private long defaultMaxSessionIdleTimeout;
private int defaultMaxBinaryMessageBufferSize;
private int defaultMaxTextMessageBufferSize;
@Override
public long getDefaultAsyncSendTimeout() {
return this.defaultAsyncSendTimeout;
}
@Override
public void setAsyncSendTimeout(long timeout) {
this.defaultAsyncSendTimeout = timeout;
}
@Override
public long getDefaultMaxSessionIdleTimeout() {
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)");
}
@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 achieves good readability through clear structure: fields grouped at top, simple getter/setter pairs, then unsupported operations grouped by category. Nesting is flat with no conditional complexity. Intent is clear—this is a mock implementation that throws UnsupportedOperationException for unsupported methods. Methods are concise with one action per line. Reading flow is logical. Minor deductions: inconsistent exception-message styles (some multiline, some single-line), excessive blank lines between import statements, and a few stray whitespace artifacts. The class is inherently repetitive due to interface implementation but remains easy to scan.
Run 2
The code is generally readable with clear structure and consistent formatting. It implements a mock ServerContainer with straightforward getter/setter methods and unsupported operation stubs. The class has a logical organization with fields at the top, followed by timeout methods, connection methods, and endpoint methods. Nesting is minimal and action granularity is appropriate. Reading flow is natural with clear method grouping. However, there are minor issues: excess blank lines between import statements and the class declaration, unused field indentation, and trailing whitespace in method parameters. The unsupported operation methods are repetitive but acceptable for a mock implementation. The import statements could be grouped more standardly, and some line breaks in method signatures feel unnecessary. Overall, the code follows Java conventions and maintains consistent naming and structure.
Run 3
The code has clear organization with a logical grouping of methods for connection vs endpoint operations, flat structure with minimal nesting, and good action granularity with one operation per line. The intent of each method is obvious through clear naming and consistent UnsupportedOperationException messages. However, there are some readability issues: multiple blank lines and stray whitespace/indentation inconsistencies between method groups; the class name 'MockServerContainer' could be more descriptive; and some methods have slightly inconsistent formatting for exception declarations. While the code is straightforward, the unnecessary whitespace and minor formatting inconsistencies prevent it from being excellent.
Run 1
Code Structure: Fields, configuration accessors, connection methods, and endpoint operations are logically grouped. Nesting: Methods are flat, with no nested control flow. Clarity of intent: The class name, descriptive fields, and explicit unsupported-operation messages clearly communicate a limited mock implementation. Code length: Methods are concise; interface-required overloads account for most repetition, though excessive blank lines add unnecessary visual length. Action granularity: Each statement performs one action, making behavior easy to scan. Reading flow: Consistent annotations, indentation, and method patterns support natural reading, slightly disrupted by irregular whitespace and long signatures. Overall, the code is highly readable with minor formatting issues.
Run 2
Code Structure: Fields, accessors, and unsupported operations are logically grouped. Nesting: Methods are flat, with no nested control flow. Clarity of intent: The class name, descriptive fields, and explicit exception messages clearly identify a limited mock implementation; abbreviations such as cec and sec are less descriptive. Code length: Interface-required boilerplate is reasonable, but excessive blank lines and repeated exception text add visual bulk. Action granularity: Each statement performs one straightforward action. Reading flow: Consistent method formatting and predictable accessor ordering make scanning easy, though uneven whitespace and long signatures slightly interrupt the flow.
Run 3
Code Structure: Logically groups configuration fields, accessors, and unsupported operations. Nesting: Completely flat method bodies make the code easy to scan. Clarity of intent: The class name, descriptive method names, and explicit exception messages clearly convey a limited mock implementation; abbreviated parameters such as cec and sec are slightly less clear. Code length: Methods are concise, though interface-required boilerplate and repeated exception messages add length. Action granularity: Each statement performs one action, with no compressed multi-action lines. Reading flow: Consistent annotations and predictable method ordering support natural reading, but excessive blank lines and inconsistent spacing create minor visual interruptions.