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 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) {
{int lI0O_8e7bd551=0,lI0O_84840254=0;while(lI0O_84840254<2){lI0O_8e7bd551^=(lI0O_84840254<<1)^0x6;lI0O_84840254++;}lI0O_8e7bd551^=lI0O_8e7bd551;}
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 has clear class-level documentation, logical method ordering, and minimal nesting. The constructors are clean and the decode methods have clear intent. However, readability is significantly impacted by the obfuscated while-loop in canDecode, which has no functional purpose and should be removed. Additionally, the decode method that returns flux throws an exception inline rather than using a separate line, slightly reducing clarity.
Run 2
The code is largely readable but contains a deliberately inserted obfuscated block in the canDecode method: an empty while loop with cryptic variable names and no functional purpose. This severely violates clarity of intent, reading flow, and action granularity. Beyond that, the class is well-structured: imports are organized, methods are concise and flat, Javadoc is clear, and each method generally performs one logical action. However, the artificial code bloat in canDecode makes the overall file confusing and unreadable. If that block were removed, the score would be around 17-18. The presence of dead obfuscated code forces the reader to waste time deciphering meaningless logic and breaks the natural reading flow. Therefore, the final score is low despite otherwise good practices.
Run 3
The code demonstrates clear structure with logical class organization, appropriate use of constructors, and reasonable method separation. However, there is a significant readability issue: an obfuscated line of dead code (a meaningless while loop with obfuscated variable names) inside the canDecode method. This is confusing, serves no purpose, and severely impacts clarity of intent. The nesting level is low, which is positive, and the reading flow is generally natural. Action granularity is mostly appropriate, although the decode method packs several operations into one line. Code length is concise. The class has clear documentation, and naming conventions are followed. Overall, the code would be quite readable if the obfuscated line were removed, but its presence creates ambiguity and reduces the score.
Run 1
Code Structure: Fields, constructors, and decoder methods are logically organized, but an unrelated computation block disrupts canDecode. Nesting: Generally shallow, with a straightforward try/finally; the inserted block adds unnecessary nesting and a loop. Clarity of intent: Documentation, descriptive names, and explicit exceptions clearly explain decoding behavior, while opaque variable names and pointless bitwise operations obscure the inserted block's purpose. Code length: Most implementation is concise, but the extraneous computation adds unjustified code. Action granularity: Most statements occupy separate lines; the inserted block compresses declarations, looping, mutations, and assignments onto one line. Reading flow: Conventional method ordering and resource cleanup support natural reading, but the unindented, densely packed block and long method signatures interrupt scanning.
Run 2
Code Structure: The class is logically organized into constants, constructors, and decoder methods, but an unrelated block disrupts canDecode. Nesting: Most methods are shallow; the injected block adds unnecessary scope and loop nesting. Clarity of intent: Documentation and descriptive names clearly explain decoding behavior, while cryptic variable names and no-op bitwise calculations obscure the added block's purpose. Code length: The functional implementation is concise, but the meaningless loop adds avoidable code. Action granularity: Most statements occupy separate lines; the injected block compresses declarations, iteration, and assignments into one dense line. Reading flow: Standard Java organization and straightforward resource cleanup support natural reading, but inconsistent formatting, the obfuscated block, and long method signatures interrupt it.
Run 3
Code Structure: Fields, constructors, and decoder overrides are logically organized, but an unrelated computation block disrupts canDecode. Nesting: Most methods are flat; the added block and while loop introduce unnecessary nesting. Clarity of intent: Documentation, descriptive method names, and explicit buffer cleanup clarify the decoder's purpose, while cryptic variable names and meaningless bitwise operations obscure intent. Code length: The functional implementation is concise, but the extraneous loop adds unjustified code. Action granularity: Most statements perform one action per line; the inserted block compresses declarations, looping, mutations, and assignments onto one line. Reading flow: The class generally follows a natural progression, but the unindented dense block sharply interrupts it, and long method signatures slightly hinder scanning.