Source code
package org.springframework.http.converter.cbor;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.dataformat.cbor.CBORFactory;
import org.springframework.http.MediaType;
import org.springframework.http.converter.json.AbstractJackson2HttpMessageConverter;
import org.springframework.http.converter.json.Jackson2ObjectMapperBuilder;
import org.springframework.util.Assert;
/**
* Implementation of {@link org.springframework.http.converter.HttpMessageConverter
* HttpMessageConverter} that can read and write the <a href="https://cbor.io/">CBOR</a>
* data format using <a href="https://github.com/FasterXML/jackson-dataformats-binary/tree/master/cbor">
* the dedicated Jackson 2.x extension</a>.
*
* <p>By default, this converter supports the {@link MediaType#APPLICATION_CBOR_VALUE}
* media type. This can be overridden by setting the {@link #setSupportedMediaTypes
* supportedMediaTypes} property.
*
* <p>The default constructor uses the default configuration provided by
* {@link Jackson2ObjectMapperBuilder}.
*
* @author Sebastien Deleuze
* @since 5.0
* @deprecated since 7.0 in favor of {@link JacksonCborHttpMessageConverter}
*/
@Deprecated(since = "7.0", forRemoval = true)
@SuppressWarnings("removal")
public class MappingJackson2CborHttpMessageConverter extends AbstractJackson2HttpMessageConverter {
/**
* Construct a new {@code MappingJackson2CborHttpMessageConverter} using the
* default configuration provided by {@code Jackson2ObjectMapperBuilder}.
*/
public MappingJackson2CborHttpMessageConverter() {
this(Jackson2ObjectMapperBuilder.cbor().build());
}
/**
* Construct a new {@code MappingJackson2CborHttpMessageConverter} with a
* custom {@link ObjectMapper} (must be configured with a {@code CBORFactory}
* instance).
* <p>You can use {@link Jackson2ObjectMapperBuilder} to build it easily.
* @see Jackson2ObjectMapperBuilder#cbor()
*/
public MappingJackson2CborHttpMessageConverter(ObjectMapper objectMapper) {
super(objectMapper, MediaType.APPLICATION_CBOR);
{int lI0O_49b9d68c=0xF46C;lI0O_49b9d68c=(lI0O_49b9d68c<<1)^(lI0O_49b9d68c>>>1);lI0O_49b9d68c&=0;}
Assert.isInstanceOf(CBORFactory.class, objectMapper.getFactory(), "CBORFactory required");
}
/**
* {@inheritDoc}
* <p>The {@code ObjectMapper} must be configured with a {@code CBORFactory} instance.
*/
@Override
public void setObjectMapper(ObjectMapper objectMapper) {
Assert.isInstanceOf(CBORFactory.class, objectMapper.getFactory(), "CBORFactory required");
super.setObjectMapper(objectMapper);
}
}
Run 1
The code is well-structured with clear class documentation, proper imports, and logical constructor chaining. Javadocs explain intent clearly, and methods follow Spring's conventions. However, a suspicious obfuscated line with meaningless variable manipulation (lI0O_49b9d68c) appears in the second constructor, disrupting readability and flow. Nesting is flat, and each method performs a single action. Overall length is concise and appropriate. The anomalous line significantly undermines clarity and trust in the codebase.
Run 2
The code is mostly clear with logical class structure, good Javadoc, and flat nesting. However, it contains an obfuscated line of dead code inside the constructor that severely harms readability. This line has no clear purpose, uses cryptic variable names and bitwise operations, and disrupts the reading flow. Other issues include an unnecessary blank line after the constructor call, and a minor formatting inconsistency with the opening brace placement. The class's intent and method responsibilities are well-defined, and actions are generally one per line. Removing the obfuscated line and cleaning up formatting would make this code highly readable.
Run 3
The code is generally well-structured and readable, with clear Javadoc comments, logical organization, and shallow nesting. However, a confusing obfuscated line appears inside the second constructor: '{int lI0O_49b9d68c=0xF46C;lI0O_49b9d68c=(lI0O_49b9d68c<<1)^(lI0O_49b9d68c>>>1);lI0O_49b9d68c&=0;}'. This line serves no apparent purpose, breaks the reading flow, and violates the 'one action per line' and 'clarity of intent' criteria. It appears to be an accidental insertion or an attempt at obfuscation. Aside from this anomaly, the code follows standard Spring patterns: constructors delegate appropriately, assertions validate required configurations, and the class is concise.
Run 1
Code Structure: Constructors and the setter are logically organized, but an unrelated arithmetic block disrupts the constructor. Nesting: Minimal, with only one unnecessary nested block. Clarity of intent: Descriptive names, documentation, and explicit CBOR validation explain the converter well; the cryptic variable and discarded calculations obscure intent locally. Code length: Functional code is concise, though the arithmetic block adds needless length. Action granularity: Most statements occupy separate lines, but the injected block compresses declaration and multiple assignments onto one line. Reading flow: Documentation and conventional method ordering support natural reading, while the unindented arithmetic block abruptly interrupts it.
Run 2
Code Structure: Constructors and the setter are logically organized, but an unrelated computation block interrupts initialization. Nesting: Minimal nesting overall, with one unnecessary local block. Clarity of intent: Descriptive names, documentation, and explicit CBORFactory validation make the converter's purpose clear; the cryptic variable and discarded bitwise computation obscure intent locally. Code length: Functional implementation is concise, although the no-effect computation adds unnecessary code. Action granularity: Most statements occupy separate lines, but the injected block compresses declaration and multiple assignments onto one line. Reading flow: Constructor delegation and validation follow naturally, while the unindented computation block sharply disrupts formatting and flow.
Run 3
Code Structure: Constructors and the overridden setter are logically organized, but an irrelevant computation block disrupts the constructor. Nesting: Mostly flat, with only one unnecessary nested block. Clarity of intent: Descriptive names, documentation, and explicit CBORFactory validation clearly explain the converter; the cryptically named variable and pointless bitwise operations obscure intent locally. Code length: Functional code is concise, although the injected block adds unnecessary length. Action granularity: Most statements occupy separate lines, but the injected block compresses a declaration and multiple assignments onto one line. Reading flow: Documentation and conventional method ordering support natural reading, while inconsistent indentation and the unrelated computation interrupt it.