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() {
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 has severe readability issues. The package and import statements are jumbled onto single lines, and method declarations are frequently crammed together with opening braces, annotations, and return statements on the same line. This violates action granularity and reading flow, forcing the reader to parse multiple logical units per line. Nesting is not deeply problematic, but the inconsistent formatting makes the structure hard to follow. While the class name and method names are clear, the intent is obscured by formatting chaos. The length is acceptable but not concise due to missing whitespace and line breaks. Overall, the code functions but reads as if auto-formatted by a minifier, not a human.
Run 2
The code suffers from severe formatting and structural issues. Multiple methods are crammed onto single lines, breaking the one-action-per-line principle. Braces are inconsistently placed, with opening braces sometimes on new lines and closing braces followed immediately by new method signatures. Import statements are disorganized and some are on the same line. The lack of whitespace between methods makes the class difficult to scan. Javadoc is present but minimal. While the logic of each method is simple (mostly throwing exceptions), the physical layout severely hampers readability and reading flow. Deeply inconsistent indentation further compounds these issues.
Run 3
The code is extremely difficult to read due to several severe issues. The import statements are jumbled, with multiple imports on single lines and inconsistent spacing. The class declares several fields but never initializes them, which is misleading. Most methods follow a simple getter/setter pattern, but the formatting is terrible — multiple methods are placed on the same line with no separation, making it nearly impossible to distinguish where one method ends and another begins. For example, getDefaultAsyncSendTimeout() and setAsyncSendTimeout() are concatenated on a single line. The connectToServer and addEndpoint methods throw UnsupportedOperationException, but the exception messages are often split awkwardly across lines. Additionally, there is no consistent indentation, line breaks are haphazard, and braces are inconsistently placed. While the class has a single clear purpose (mocking ServerContainer), the implementation completely disregards standard Java formatting conventions, making the code almost unreadable despite its simplicity. The lack of field initialization and the repetitive, poorly formatted exception-throwing methods further reduce clarity.
Run 1
Code Structure: Fields and methods are logically grouped by interface responsibilities, but inconsistent formatting obscures boundaries. Nesting: Methods are flat and simple, with no complex control flow. Clarity of intent: Descriptive names, class documentation, and explicit unsupported-operation messages clearly convey the mock's purpose. Code length: The implementation is reasonably concise; repeated exception messages are mostly justified by interface requirements. Action granularity: Several imports, annotations, method declarations, and closing braces share lines, making individual elements harder to distinguish. Reading flow: Irregular whitespace, compressed methods, and section comments attached to preceding code interrupt scanning. Overall, straightforward logic and clear naming preserve readability, but poor layout significantly reduces it.
Run 2
Code Structure: Fields and interface methods are logically grouped, but inconsistent formatting obscures method boundaries and section comments. Nesting: Very flat, with no nested control flow. Clarity of intent: Descriptive names, class documentation, straightforward accessors, and explicit unsupported-operation messages clearly communicate the mock's purpose. Code length: Reasonably concise for implementing the interface; repeated exception messages add some verbosity but remain useful. Action granularity: Several imports, annotations, method declarations, and statements share lines, making individual elements harder to distinguish. Reading flow: Irregular line breaks, spacing, and brace placement disrupt scanning, especially where one method ends and another begins. Overall, simple logic and clear naming preserve readability, but formatting significantly reduces it.
Run 3
Code Structure: Fields and methods are logically grouped by interface responsibilities, but inconsistent formatting obscures boundaries. Nesting: Very shallow, with no complex branching or loops. Clarity of intent: Descriptive names, class documentation, and explicit unsupported-operation messages clearly communicate the mock's purpose. Code length: Reasonably concise for an interface implementation; repetitive getters, setters, and exception methods are largely necessary. Action granularity: Several imports, annotations, method declarations, and statements share lines, making individual operations harder to distinguish. Reading flow: Irregular indentation, crowded method boundaries, and inconsistent line breaks repeatedly interrupt scanning. The underlying logic is straightforward, but presentation significantly reduces readability.