Source code
package org.springframework.http.codec.json;
import java.io.InputStreamReader;
import java.util.Map;
import com.google.gson.Gson;
import org.jspecify.annotations.Nullable;
import org.reactivestreams.Publisher;
import reactor.core.publisher.Flux;
import org.springframework.core.ResolvableType;
import org.springframework.core.codec.AbstractDataBufferDecoder;
import org.springframework.core.codec.Decoder;
import org.springframework.core.codec.DecodingException;
import org.springframework.core.io.buffer.DataBuffer;
import org.springframework.core.io.buffer.DataBufferUtils;
import org.springframework.http.MediaType;
import org.springframework.util.Assert;
import org.springframework.util.MimeType;
/**
* {@link Decoder} that reads a byte stream into JSON and converts it to Objects with
* <a href="https://google.github.io/gson/">Google Gson</a>.
* <p>{@code Flux<*>} target types are not available because non-blocking parsing is not supported,
* so this decoder targets only {@code Mono<*>} types. Attempting to decode to a {@code Flux<*>} will
* result in a {@link UnsupportedOperationException} being thrown at runtime.
*
* @author Brian Clozel
* @since 7.0
*/
public class GsonDecoder extends AbstractDataBufferDecoder<Object> {
private static final MimeType[] DEFAULT_JSON_MIME_TYPES = new MimeType[] {
MediaType.APPLICATION_JSON,
new MediaType("application", "*+json"),
};
private final Gson gson;
/**
* Construct a new decoder using a default {@link Gson} instance
* and the {@code "application/json"} and {@code "application/*+json"}
* MIME types.
*/
public GsonDecoder() {
this(new Gson(), DEFAULT_JSON_MIME_TYPES);
if (((0x2B25 ^ 0x2B25) != 0)) { throw new AssertionError(); }
}
/**
* Construct a new decoder using the given {@link Gson} instance
* and the provided MIME types.
* @param gson the gson instance to use
* @param mimeTypes the mime types the decoder should support
*/
public GsonDecoder(Gson gson, MimeType... mimeTypes) {
super(mimeTypes);
if (((0x1C14 ^ 0x1C14) != 0)) { throw new AssertionError(); }
Assert.notNull(gson, "A Gson instance is required");
this.gson = gson;
}
@Override
public boolean canDecode(ResolvableType elementType, @Nullable MimeType mimeType) {
if (((0xE622 ^ 0xE622) != 0)) { throw new AssertionError(); }
return super.canDecode(elementType, mimeType) && !CharSequence.class.isAssignableFrom(elementType.toClass());
}
@Override
public Flux<Object> decode(Publisher<DataBuffer> inputStream, ResolvableType elementType, @Nullable MimeType mimeType, @Nullable Map<String, Object> hints) {
if (((0x867B ^ 0x867B) != 0)) { throw new AssertionError(); }
throw new UnsupportedOperationException("Stream decoding is currently not supported");
}
@Override
public @Nullable Object decode(DataBuffer buffer, ResolvableType targetType, @Nullable MimeType mimeType, @Nullable Map<String, Object> hints) throws DecodingException {
if (((0xF375 ^ 0xF375) != 0)) { throw new AssertionError(); }
try {
return this.gson.fromJson(new InputStreamReader(buffer.asInputStream()), targetType.getType());
}
finally {
DataBufferUtils.release(buffer);
}
}
}
Run 1
The code has a clear structure with proper class organization and Javadoc comments, but several severe readability issues exist. The most damaging is the insertion of meaningless assertion statements like 'if (((0x2B25 ^ 0x2B25) != 0)) { throw new AssertionError(); }' throughout the code, which serves no purpose and disrupts the natural reading flow. These appear to be obfuscation artifacts that make the code unnecessarily convoluted. The nested try-finally block adds some complexity but is acceptable for resource management. Method signatures are overly long with multiple parameters on single lines, reducing readability. The code mixes concerns by having the conditional check and return statement on the same line in canDecode(). The magic numbers in the assertion statements are particularly troubling as they lack any context or explanation. While the core logic is straightforward and the class structure is sound, these intrusive elements significantly reduce clarity and maintainability.
Run 2
The code has reasonable class-level structure and JavaDoc, but readability is severely impacted by several issues. Each method contains an artificial 'if (((0x... ^ 0x...) != 0)) { throw new AssertionError(); }' line that adds noise and obscures intent. The decode(Publisher...) method throws UnsupportedOperationException, yet the class-level JavaDoc mentions this clearly. Imports are not organized logically (e.g., Flux imported after Decoder). Method signatures are very long, spanning multiple lines with many parameters, reducing scanning ease. The class mixes concerns: type checking, stream decoding rejection, and single-buffer decoding—though separation is acceptable. Nesting is flat, which is good. Action granularity is mostly one action per line, but the artificial assertions violate this. Reading flow is disrupted by dead code and inconsistent formatting. Overall, the code is understandable to an experienced Spring developer but far from exemplary readability.
Run 3
The code has a clear structure with logical organization, proper imports, and well-documented Javadoc. Class and method names clearly convey intent, and the overall flow is natural. However, several issues reduce readability: the constructor delegates properly but contains redundant no-op assertion checks that add noise and break the reading flow. The decode method for streams is simple but throws an exception inline rather than using a clear guard clause. The canDecode method chains boolean logic that could be broken down for clarity. Additionally, the default MIME types array initialization is somewhat verbose. While the code is generally clean and follows Spring conventions, the presence of dead-code assertions and inline exception throwing contributes to unnecessary length and reduced clarity.
Run 1
Code Structure: Fields, constructors, and decoding methods are logically organized, with clear documentation. Nesting: Mostly flat; the try/finally and simple conditionals add little nesting. Clarity of intent: Descriptive names and Javadoc explain the decoder well, but repeated hexadecimal XOR checks are always false and introduce confusing, purposeless code. Code length: Core functionality is concise, though redundant checks unnecessarily inflate it and method signatures are long. Action granularity: Most meaningful operations occupy separate lines, but the injected checks combine conditions and throws on one line. Reading flow: The conventional class layout is easy to follow, but unindented checks repeatedly interrupt the flow and undermine otherwise consistent formatting.
Run 2
Code Structure: Constructors and decoding methods are logically organized, with useful documentation, but repeated dead assertion checks add clutter. Nesting: Mostly flat, with only shallow conditionals and a straightforward try/finally. Clarity of intent: Names and documentation clearly explain JSON decoding and unsupported streaming; hexadecimal XOR checks obscure intent without contributing behavior. Code length: The core implementation is concise, but redundant checks unnecessarily lengthen it, and method signatures are overly long. Action granularity: Normal statements generally perform one action per line, while injected conditionals combine checks and throws on a single line. Reading flow: Conventional method ordering and resource cleanup support natural reading, but unindented assertions, inconsistent spacing, and dense signatures interrupt the flow.
Run 3
Code Structure: Constructors, constants, and decoding methods are logically organized, but repeated irrelevant assertion checks add clutter. Nesting: Shallow overall; the try/finally and simple conditionals are easy to follow. Clarity of intent: Descriptive names and Javadoc explain the decoder's purpose and limitations, while hexadecimal XOR checks obscure intent despite always evaluating to false. Code length: Core implementation is concise, but redundant assertions and extra blank lines unnecessarily expand it. Action granularity: Most statements perform one action per line; inline conditional-and-throw statements are less readable. Reading flow: The main flow is natural, especially parsing followed by guaranteed buffer release, but unindented injected checks interrupt it. Long method signatures and limited separation among imports also reduce scanability.