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); 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 has clear intent and is logically organized, but formatting severely hampers readability. Imports are correctly grouped, and the class has clear Javadoc. However, multiple statements are placed on single lines (e.g., class declaration with constructor, method declarations with logic), violating action granularity and natural flow. Braces are misaligned in several places, making structure harder to follow. Nesting is minimal, but code length is unnecessarily compacted. The deprecation annotations and Assert checks are clear, but the compressed formatting obscures the logical separation of concerns.
Run 2
The code lacks proper line breaks and consistent indentation, making it visually dense and hard to scan. Multiple statements share lines, class declarations merge with methods, and import statements are not cleanly separated. While the logic and intent are straightforward, the formatting hurts readability. Javadoc comments are well-written but poorly integrated into the code layout. Restructuring with proper line breaks, one action per line, and cleaner method separation would significantly improve readability.
Run 3
The code is moderately readable but suffers from formatting and structural issues. The class has a clear purpose and follows standard Spring converter patterns, with helpful Javadoc explaining usage. However, imports are crammed onto single lines, multiple methods and Javadoc blocks appear on the same line as declarations, and the constructor bodies lack proper line breaks. This creates dense, difficult-to-scan code. Nesting is acceptable (flat structure), and each method performs one logical action, but the reading flow is disrupted by poor vertical spacing and line organization. The overridden setObjectMapper method is straightforward but its opening brace placement harms readability. Overall, the code would be significantly improved with standard formatting: one import per line, separated Javadoc blocks, and proper line breaks between declarations and method bodies.
Run 1
Code Structure: The class is logically organized into constructors and an overridden setter, but compressed formatting obscures member boundaries. Nesting: Minimal nesting makes the logic easy to follow. Clarity of intent: Descriptive names, detailed documentation, and explicit CBORFactory validation clearly communicate purpose and requirements. Code length: The implementation is concise; documentation is longer than the logic but useful. Action granularity: Multiple imports and constructor statements share lines, while annotations, declarations, comments, and closing braces are inconsistently combined. Reading flow: The default-to-custom constructor delegation and setter validation follow a natural sequence, but missing spacing and irregular line breaks interrupt scanning. Overall, straightforward functionality and strong documentation are undermined by poor formatting.
Run 2
Code Structure: The class is logically organized into constructors and an overridden setter, but inconsistent formatting obscures member boundaries. Nesting: Minimal nesting makes the logic easy to follow. Clarity of intent: Descriptive names, detailed documentation, and explicit CBORFactory checks clearly communicate purpose and constraints. Code length: The implementation is concise; documentation is longer than the executable code but provides useful context. Action granularity: Multiple imports and constructor statements share lines, reducing scanability and violating one-action-per-line formatting. Reading flow: The order is natural, but comments attached to braces, annotations sharing declaration lines, and closing braces appended to statements interrupt smooth reading.
Run 3
Code Structure: Imports, documentation, constructors, and the override are logically organized, but compressed formatting obscures their boundaries. Nesting: Very shallow, with no conditional or loop nesting. Clarity of intent: Descriptive names and useful Javadoc clearly explain CBOR support and ObjectMapper validation. Code length: The implementation is concise without unnecessary logic; documentation is proportionate. Action granularity: Multiple imports and constructor statements share lines, making individual actions harder to scan. Reading flow: The conventional class layout helps, but comments attached to braces, annotations sharing method declaration lines, and inline closing braces interrupt natural reading. Consistent line breaks and spacing would substantially improve readability.