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;
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;
public GsonDecoder() {
this(new Gson(), DEFAULT_JSON_MIME_TYPES);
}
public GsonDecoder(Gson gson, MimeType... mimeTypes) {
super(mimeTypes);
Assert.notNull(gson, "A Gson instance is required");
this.gson = gson;
}
@Override
public boolean canDecode(ResolvableType elementType, @Nullable MimeType mimeType) {
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) {
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 {
try {
return this.gson.fromJson(new InputStreamReader(buffer.asInputStream()), targetType.getType());
}
finally {
DataBufferUtils.release(buffer);
}
}
}
Run 1
The code is generally well-structured and readable. It follows a clean class layout with fields, constructors, and overridden methods, and each method is concise with a single clear responsibility. Nesting is minimal, and intent is mostly clear. However, readability is slightly reduced by a long decode method chain, long parameter lists on decode methods, and a mildly convoluted canDecode condition. Overall, it is a short, focused class with only minor style issues.
Run 2
The code is generally well-structured and readable. It follows Spring framework conventions, with clear class and method organization. Imports are ordered and the class has a single responsibility. The constructor delegation is clean and the `canDecode` method is concise with clear intent. However, there are minor readability issues: several blank lines of irregular length between members (e.g., 5–10 empty lines) disrupt reading flow, and the `decode` method combining `fromJson` with `InputStreamReader` on one line slightly reduces action granularity. Nesting is minimal (only one try-finally), and naming is clear. The unsupported stream decode method explicitly throws an exception, which is good for clarity. Overall, the code is readable but could be improved by consistent spacing and splitting the Gson parsing expression into a separate line for clarity.
Run 3
The code is generally well-structured and readable. It has clear class organization, minimal nesting, and explicit method intents. Imports are grouped, fields are logically placed, and constructors are straightforward. However, readability is slightly reduced by the overly long method signatures in decode() and canDecode(), which exceed comfortable line lengths and contain multiple parameters. The unsupported stream decoding method throws an exception but its purpose is clear. Action granularity is mostly one-per-line, though the gson.fromJson call combines multiple nested operations. Overall, the code is concise and maintainable but could benefit from line wrapping on long signatures.
Run 1
Code Structure: Constants, state, constructors, and overridden methods are logically organized. Nesting: Minimal nesting, with only a straightforward try/finally block. Clarity of intent: Descriptive names and familiar decoder methods make the purpose clear; the unsupported streaming operation is explicitly identified. Code length: Implementation is concise, but excessive blank lines add unnecessary visual length, and long method signatures reduce scanability. Action granularity: Each statement performs a single clear action; the inline reader construction remains easy to understand. Reading flow: Initialization, capability checking, and decoding follow a natural sequence, with buffer cleanup clearly separated. Inconsistent whitespace and unwrapped signatures slightly disrupt an otherwise readable implementation.
Run 2
Code Structure: Constants, state, constructors, and decoding methods are logically organized. Nesting: Minimal nesting, with a straightforward try/finally block. Clarity of intent: Descriptive names and standard overrides make the decoder's purpose clear; the exception explicitly identifies unsupported streaming. Code length: Implementation is concise, but excessive blank lines add unnecessary visual length. Action granularity: Most lines perform one action, though the JSON parsing expression combines stream access, reader construction, type resolution, and deserialization. Reading flow: Method order is natural and resource release is easy to follow, but long signatures, ungrouped imports, and irregular whitespace interrupt scanning.
Run 3
Code Structure: Logically organized into configuration, constructors, capability checking, and decoding methods. Nesting: Minimal; only a straightforward try/finally block. Clarity of intent: Descriptive names and explicit exceptions make behavior clear, though the distinction between unsupported stream decoding and supported buffer decoding could benefit from documentation. Code length: Implementation is concise, but excessive blank lines add unnecessary visual length. Action granularity: Generally one action per line; the nested reader construction and deserialization expression remain understandable. Reading flow: Method ordering is natural, but long signatures, sparse import grouping, and irregular whitespace interrupt scanning.