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 a, MimeType... b) {
super(b);
Assert.notNull(a, "A Gson instance is required");
this.gson = a;
}
@Override
public boolean a(ResolvableType c, @Nullable MimeType d) {
return super.canDecode(c, d) && !CharSequence.class.isAssignableFrom(c.toClass());
}
@Override
public Flux<Object> b(Publisher<DataBuffer> e, ResolvableType f, @Nullable MimeType g, @Nullable Map<String, Object> h) {
throw new UnsupportedOperationException("Stream decoding is currently not supported");
}
@Override
public @Nullable Object b(DataBuffer i, ResolvableType j, @Nullable MimeType k, @Nullable Map<String, Object> l) throws DecodingException {
try {
return this.gson.fromJson(new InputStreamReader(i.asInputStream()), j.getType());
}
finally {
DataBufferUtils.release(i);
}
}
}
Run 1
The code has good documentation and clear field definitions, but readability is severely compromised by poor naming conventions. Parameters are named 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l' which completely obscures intent. Method names 'a()' and 'b()' provide no information about their purpose. This forces readers to infer behavior from context rather than code clarity. The class structure is otherwise logical with proper constructors and separation of concerns, but the horrendous naming defeats the purpose of self-documenting code. The code is relatively flat (good), action granularity is acceptable, and length is reasonable. However, the cryptic parameter names make the code nearly impossible to maintain without cross-referencing documentation. This appears to be obfuscated or decompiled code, which explains the naming issues but doesn't excuse them in a production codebase. The score reflects good structure undermined by unfathomable naming.
Run 2
The code has some readability but is undermined by poor method/variable naming in the overridden methods. The Javadoc and class-level structure are clear, and the constructors are logical. However, the critical methods use meaningless single-letter parameters (a, b, c, d, etc.) that obscure intent. For example, `a(ResolvableType c, MimeType d)` gives no indication of what the method does or what the parameters represent. The method bodies are short, and nesting is minimal, but the renamed methods break reading flow and clarity. The `decode` method for `DataBuffer` is relatively straightforward, but the stream-decoding method throws unconditionally, which is clear but somewhat awkward. Action granularity is acceptable—one action per line mostly. Overall, the structure is fine, but naming significantly hurts readability, making it harder to understand than it should be.
Run 3
The code has a reasonable class structure and Javadoc, but the method names are single letters (a, b), parameter names are meaningless (a, b, c, d, e, f, g, h, i, j, k, l), and one overload uses 'a' for a Gson parameter while another uses 'a' for a method name, all of which makes the intent completely unclear. There is inconsistent parameter naming between the two constructors (e.g., 'gson' vs 'a'). Multiple actions occur per line in some methods (e.g., throwing in one line, return with nested calls). The overridden methods lack @Override annotations, breaking convention and clarity. While the class-level documentation is helpful and the logic appears simple, the obfuscated naming, lack of semantic parameter names, and inconsistent style severely harm readability.
Run 1
Code Structure: Clearly organized into constants, a field, constructors, and decoding methods. Nesting: Minimal; the only control structure is a straightforward try/finally. Clarity of intent: Class documentation explains the purpose well, but single-letter method and parameter names obscure meaning. Constructor documentation references names that no longer match its parameters, and the renamed @Override methods make the intended API relationship confusing. Code length: Concise implementation with generally useful documentation. Action granularity: Statements mostly perform one action per line, although the parsing expression combines stream access, reader construction, and deserialization. Reading flow: Conventional ordering and spacing help, but long signatures and indistinguishable overloaded method names require readers to infer roles from types.
Run 2
Code Structure: The class is logically organized into constants, a dependency field, constructors, and decoding methods. Nesting: Minimal nesting and a straightforward try/finally keep control flow easy to follow. Clarity of intent: Class documentation and recognizable API calls explain the overall purpose, but single-letter method and parameter names obscure individual responsibilities. Constructor documentation names parameters that no longer match the signature, and renamed @Override methods conflict with the apparent superclass API, adding confusion. Code length: The implementation is concise, with little unnecessary logic. Action granularity: Statements generally perform one action per line, though inline reader creation slightly compresses the decoding operation. Reading flow: Conventional ordering and formatting help, but ambiguous names, overloaded methods named b, and tightly packed imports interrupt otherwise natural reading.
Run 3
Code Structure: Fields, constructors, and decoding methods are logically organized, with resource cleanup clearly separated. Nesting: Minimal nesting; the only control structure is a straightforward try/finally. Clarity of intent: Class documentation explains the purpose and streaming limitation, but single-letter method and parameter names obscure roles. Constructor documentation references names that do not match its parameters, and renamed override methods conflict with the apparent inherited API. Code length: Compact without unnecessary implementation detail. Action granularity: Statements generally perform one action per line, though the parsing expression combines stream access, reader construction, and deserialization. Reading flow: Conventional Java organization and spacing help navigation, but overloaded methods named b and parameters a through l force readers to infer meaning from types and usage.