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);
}
/**
* 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 gso, MimeType... mime) {
super(mime);
Assert.notNull(gso, "A Gson instance is required");
this.gson = gso;
}
@Override
public boolean can(ResolvableType element, @Nullable MimeType mime2) {
return super.canDecode(element, mime2) && !CharSequence.class.isAssignableFrom(element.toClass());
}
@Override
public Flux<Object> dec(Publisher<DataBuffer> input, ResolvableType element2, @Nullable MimeType mime3, @Nullable Map<String, Object> hin) {
throw new UnsupportedOperationException("Stream decoding is currently not supported");
}
@Override
public @Nullable Object dec(DataBuffer buf, ResolvableType target, @Nullable MimeType mime4, @Nullable Map<String, Object> hin2) throws DecodingException {
try {
return this.gson.fromJson(new InputStreamReader(buf.asInputStream()), target.getType());
}
finally {
DataBufferUtils.release(buf);
}
}
}
Run 1
The code is generally readable and structured logically with clear class-level documentation and constructor overloads. However, several issues reduce its readability: method names like 'can', 'dec', 'hin', and parameter names such as 'gso', 'mime', 'mime2', 'element2', 'hin2' are cryptic and inconsistent, obscuring intent. The parameter naming is confusing (e.g., 'gso' for 'gson', 'mime' and 'mime2'), suggesting copy-paste or incomplete renaming. The 'can' method name is ambiguous; a clearer name like 'canDecode' would be better. The code has moderate nesting, mostly flat, and action granularity is fine. The mixed naming conventions and inconsistent parameter names disrupt reading flow and clarity. Overall, while the structure is acceptable, the clarity of intent suffers significantly due to poor naming, lowering the readability score.
Run 2
The code has a clear purpose and generally follows standard Java conventions, but several issues reduce readability. The method names and parameters are heavily abbreviated (e.g., 'can', 'dec', 'gso', 'mime', 'hin') which obscures intent. Inconsistent naming (e.g., 'gso' vs 'gson', 'mime2' through 'mime4') creates confusion. The class overrides methods but uses different parameter names than the parent, making it harder to understand the contract. The constructor parameter 'gso' should be 'gson' to match the field. The canDecode logic is concise but the 'can' override is misleadingly named. Error handling is simple, and the overall structure is acceptable, but the poor naming choices and parameter inconsistencies significantly impact clarity.
Run 3
The code has reasonable structure with a clear class purpose and basic Javadoc, but readability is significantly hurt by poor naming and inconsistent style. Methods like 'can', 'dec', 'dec' (overloaded), and parameters like 'gso', 'mime2', 'buf', 'hin2', 'element2' obscure intent and force readers to guess meaning. The two 'dec' methods with similar names but different signatures create confusion. The try-finally block is flat and action granularity is okay, but the overall reading flow is disrupted by abbreviations and inconsistent parameter naming across methods. Import organization is acceptable. The class would benefit from descriptive method names, consistent parameters, and clearer separation of concerns. Overall, the code is functional but requires extra mental effort to understand, earning a low-middle readability score.
Run 1
Code Structure: Fields, constructors, and decoding methods are logically organized, with helpful class documentation. Nesting: Minimal nesting; the try/finally block is straightforward. Clarity of intent: Gson conversion and buffer cleanup are clear, but abbreviated method names (can, dec) and inconsistent parameter names (gso, mime2, hin2) obscure meaning. Constructor documentation also names parameters differently from the signature. The apparent mismatch between overridden method names and the decoder API creates additional confusion. Code length: Compact implementation with mostly useful documentation, though long method signatures reduce scanability. Action granularity: Statements generally perform one action per line; the nested reader construction and parsing expression remain manageable. Reading flow: Conventional ordering and consistent indentation support natural reading, but compressed imports, long lines, and inconsistent naming interrupt the flow.
Run 2
Code Structure: Fields, constructors, and decoding methods are logically organized, though abbreviated method names conflict with the apparent overridden API. Nesting: Minimal; the simple try/finally is easy to follow. Clarity of intent: Class documentation and Gson calls explain the purpose, but names such as can, dec, gso, hin2, and mime4 obscure roles. Constructor documentation also names parameters differently from the signature. Code length: Compact and largely free of unnecessary logic, although long method signatures reduce scanability. Action granularity: Statements generally perform one action each; the nested reader creation is still understandable. Reading flow: Conventional class organization and consistent indentation support natural reading, but inconsistent naming and densely packed imports interrupt it.
Run 3
Code Structure: Well organized into constants, a dependency field, constructors, and decoding methods, with resource cleanup clearly separated. Nesting: Minimal; only a straightforward try/finally block. Clarity of intent: Class documentation and Gson calls explain the purpose, but abbreviated method names (can, dec) and inconsistent parameter names (gso, mime2, hin2) reduce clarity. Constructor documentation also references names that differ from the actual parameters, and renamed override methods obscure their relationship to the superclass API. Code length: Concise, with little unnecessary implementation code, though long signatures are harder to scan. Action granularity: Statements generally perform one action per line; the nested reader construction and parsing expression remains manageable. Reading flow: Logical top-to-bottom progression and consistent indentation help, but dense imports, unwrapped signatures, and arbitrary naming interrupt otherwise natural reading.