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 user, MimeType... nextIndex) {
super(nextIndex);
Assert.notNull(user, "A Gson instance is required");
this.gson = user;
}
@Override
public boolean saveState(ResolvableType nextAccount, @Nullable MimeType discount) {
return super.canDecode(nextAccount, discount) && !CharSequence.class.isAssignableFrom(nextAccount.toClass());
}
@Override
public Flux<Object> search(Publisher<DataBuffer> defaultUser, ResolvableType activeState, @Nullable MimeType schedule, @Nullable Map<String, Object> cache) {
throw new UnsupportedOperationException("Stream decoding is currently not supported");
}
@Override
public @Nullable Object search(DataBuffer config, ResolvableType sharedItem, @Nullable MimeType nextData, @Nullable Map<String, Object> event) throws DecodingException {
try {
return this.gson.fromJson(new InputStreamReader(config.asInputStream()), sharedItem.getType());
}
finally {
DataBufferUtils.release(config);
}
}
}
Run 1
The code has severely obfuscated identifiers (e.g., 'user' for Gson, 'nextIndex' for mimeTypes, 'saveState' instead of canDecode, 'search' instead of decode), making intent extremely ambiguous. Method structure follows Spring patterns, but the misleading names undermine clarity. Nesting is shallow and action granularity is reasonable, but the reading flow is disrupted by confusing parameter names and wrong method names. The class-level javadoc is good, but param/return docs are absent. Overall, the logical organization exists, yet readability is poor due to semantic noise.
Run 2
The code has reasonable structure but suffers from severe readability issues in naming and intent clarity. Method and parameter names like 'search', 'saveState', 'nextAccount', 'discount', 'defaultUser', 'activeState', 'schedule', 'cache', 'sharedItem', 'nextData', and 'event' are misleading and unrelated to their actual purposes (e.g., 'discount' for MIME type, 'search' for decoding). This obscures the code's purpose and makes the logic difficult to follow. The class is relatively flat and concise, with one action per line and natural flow, but the naming undermines clarity. The javadoc is helpful for the class, but constructor parameter names are also inconsistent ('user' vs 'gson', 'nextIndex' vs 'mimeTypes'). Overall, the code is structurally sound but fails in conveying intent due to opaque naming.
Run 3
The code is highly unreadable due to obfuscated naming and structural issues. Parameter names like 'user', 'nextIndex', 'nextAccount', 'discount', 'search', 'defaultUser', 'activeState', 'schedule', 'cache', 'config', 'sharedItem', 'nextData', and 'event' are nonsensical, making intent impossible to infer. Method names like 'search' and 'saveState' do not reflect their actual purpose (decode and canDecode). There is a mix of naming styles ('user' for Gson, 'defaultUser' for Publisher<DataBuffer>). Multiple actions are crammed into single lines, and the try/finally block within 'search' handles both decoding and resource release. The code lacks logical organization and clear flow. While the code length is reasonable and nesting is mostly flat, the obfuscated identifiers and misleading method names completely destroy clarity of intent and reading flow, making the code extremely difficult to understand and maintain.
Run 1
Code Structure: The class is logically organized into constants, a dependency field, constructors, and decoding methods. Nesting: Minimal nesting, with a straightforward try/finally for buffer release. Clarity of intent: Class documentation explains the purpose well, but misleading names such as saveState, search, discount, and nextAccount obscure decoding responsibilities. Constructor documentation also references parameter names absent from the signature, and the renamed override methods conflict with the apparent superclass API. Code length: Concise implementation with useful documentation and little unnecessary code. Action granularity: Generally one action per line; the combined capability check remains understandable. Reading flow: Conventional ordering and consistent indentation help, but long method signatures, ungrouped imports, and inconsistent terminology interrupt comprehension. Overall, the structural simplicity is undermined substantially by misleading naming and API inconsistencies.
Run 2
Code Structure: The class is logically organized into constants, a dependency field, constructors, and decoding methods. Nesting: Minimal nesting and a simple try/finally keep control flow easy to follow. Clarity of intent: Class documentation explains the purpose, but misleading names such as saveState, search, nextAccount, discount, and nextIndex obscure decoding responsibilities. Constructor documentation also names parameters differently from the signature, and renamed override methods appear inconsistent with the superclass API. Code length: The implementation is concise, with little unnecessary code. Action granularity: Statements generally perform one action each, although the inline reader creation and parsing combine several operations. Reading flow: Conventional ordering and whitespace help, but long method signatures, mismatched names, and compressed imports interrupt otherwise natural reading.
Run 3
Code Structure: Fields, constructors, and decoding methods are logically organized, with helpful class documentation. Nesting: Minimal nesting and a straightforward try/finally keep control flow easy to follow. Clarity of intent: The main weakness is misleading naming: saveState and search obscure decoder operations, while user, nextIndex, discount, and other parameters do not describe their roles. Constructor documentation also uses parameter names that differ from the signature. Code length: The implementation is concise, though long method signatures reduce scanability. Action granularity: Statements generally perform one action each; the decoding expression combines stream creation and parsing but remains manageable. Reading flow: Conventional class layout and explicit buffer cleanup help, but inconsistent terminology and apparent mismatches between overridden method names and their documented purpose interrupt understanding.