Source code
package io.netty.handler.codec.http3;
/**
* State of encoding or decoding for a stream following the <a
* href="https://quicwg.org/base-drafts/draft-ietf-quic-http.html#name-http-message-exchanges">
* HTTP message exchange semantics</a>
*/
interface Http3RequestStreamCodecState {
/**
* An implementation of {@link Http3RequestStreamCodecState} that managed no state.
*/
Http3RequestStreamCodecState NO_STATE = new Http3RequestStreamCodecState() {
@Override
public boolean started() {
return false;
}
@Override
public boolean receivedFinalHeaders() {
return false;
}
@Override
public boolean terminated() {
return false;
}
};
/**
* If any {@link Http3HeadersFrame} or {@link Http3DataFrame} has been received/sent on this stream.
*
* @return {@code true} if any {@link Http3HeadersFrame} or {@link Http3DataFrame} has been received/sent on this
* stream.
*/
boolean started();
/**
* If a final {@link Http3HeadersFrame} has been received/sent before {@link Http3DataFrame} starts.
*
* @return {@code true} if a final {@link Http3HeadersFrame} has been received/sent before {@link Http3DataFrame}
* starts
*/
boolean receivedFinalHeaders();
/**
* If no more frames are expected on this stream.
*
* @return {@code true} if no more frames are expected on this stream.
*/
boolean terminated();
}
Run 1
The code is highly readable. It uses a clean interface with clear, well-documented methods that describe HTTP/3 stream state. The structure is logical: a constant NO_STATE provides an immutable no-op implementation, and the three state-checking methods are purpose-driven and concise. Nesting is minimal—only one anonymous inner class with flat method overrides. Each method has a single clear action and Javadoc explains intent and edge cases. Reading flow is natural, moving from interface purpose to a default implementation to query methods. Minor deductions: the anonymous class adds slight verbosity, and the Javadoc references could be simplified, but overall the code is nearly ideal in clarity and structure.
Run 2
The code is highly readable. The interface is logically structured with clear separation of state methods. Nesting is minimal—only a single anonymous inner class for NO_STATE. Intent is explicit through descriptive method names and thorough Javadoc comments explaining each state condition. Code length is concise: each method is a one-line boolean getter, and the class is not burdened with unnecessary logic. Action granularity is appropriate, with one action per line within the NO_STATE implementation. Reading flow is natural, moving from the state definition to the default no-state implementation and then to method declarations. Minor deductions: the Javadoc for NO_STATE contains a minor grammatical issue ('managed' should be 'manages'), and the interface could potentially be simplified using default methods, but these are trivial. Overall, this is exemplary code in terms of structure, clarity, and maintainability.
Run 3
The code is highly readable. It has a clear, logical structure with a well-defined interface and a simple anonymous implementation. Nesting is minimal—just one level for the method overrides. The intent is evident from the descriptive method names and thorough Javadoc comments explaining each method's purpose and return value. The code is concise, with no unnecessary boilerplate beyond what's required for an interface and its default implementation. Each method override is a single action, improving clarity. The reading flow is natural: package declaration, import, interface declaration, constant, then method declarations. Minor deductions: the Javadoc could link to the specific HTTP/3 RFC section more precisely, and the anonymous class could be replaced with a lambda if the interface had a single method, but these are trivial improvements.
Run 1
Code Structure: The interface cleanly groups a stateless implementation and three related state queries. Nesting: Minimal; the anonymous implementation adds only one shallow level. Clarity of intent: Descriptive method names and Javadoc clearly explain stream lifecycle states, although receivedFinalHeaders() sounds receive-specific despite documenting both sending and receiving. Code length: Appropriately short, with slight verbosity from repetitive Javadoc and constant-false implementations. Action granularity: Each method performs one simple action, with no compound statements. Reading flow: Consistent formatting and logical ordering from started to final headers to terminated make the code easy to follow. Minor documentation issues, including 'managed no state' and repeated descriptions, slightly reduce polish.
Run 2
Code Structure: The interface logically groups three state queries and a clearly named NO_STATE implementation. Nesting: Only shallow nesting appears in the anonymous implementation, with no complex control flow. Clarity of intent: Descriptive method names and Javadoc make the stream-state contract clear, although receivedFinalHeaders() is slightly inconsistent with documentation describing both receiving and sending. Code length: The implementation is concise; repeated Javadoc descriptions add minor verbosity. Action granularity: Each method performs a single action, with one return statement per line. Reading flow: Consistent formatting and method ordering make the code easy to scan, and the NO_STATE implementation mirrors the interface declarations.
Run 3
Code Structure: The interface logically groups three state queries and a clearly identified stateless implementation. Nesting: Only shallow nesting appears in the anonymous implementation; there is no complex control flow. Clarity of intent: Descriptive method names and Javadoc explain the stream lifecycle, although receivedFinalHeaders() sounds receive-only despite documenting both sending and receiving. Code length: The code is compact overall, with minor verbosity from repeated Javadoc descriptions and three constant-return methods. Action granularity: Each method performs a single action, and statements are cleanly separated. Reading flow: Consistent formatting and spacing make the code easy to scan; placing NO_STATE before the method declarations is understandable. Minor grammatical issues in documentation slightly reduce polish.