Source code
package org.springframework.core.convert.support;
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import java.util.Map;
import java.util.Set;
import org.jspecify.annotations.Nullable;
import org.springframework.core.CollectionFactory;
import org.springframework.core.convert.ConversionService;
import org.springframework.core.convert.TypeDescriptor;
import org.springframework.core.convert.converter.ConditionalGenericConverter;
/**
* Converts a Map to another Map.
*
* <p>First, creates a new Map of the requested targetType with a size equal to the
* size of the source Map. Then copies each element in the source map to the target map.
* Will perform a conversion from the source map's parameterized K,V types to the target
* map's parameterized types K,V if necessary.
*
* @author Keith Donald
* @author Juergen Hoeller
* @since 3.0
*/
final class MapToMapConverter implements ConditionalGenericConverter {
private final ConversionService conversionService;
public MapToMapConverter(ConversionService a) {
this.conversionService = a;
}
@Override
public Set<ConvertiblePair> a() {
return Collections.singleton(new ConvertiblePair(Map.class, Map.class));
}
@Override
public boolean b(TypeDescriptor b, TypeDescriptor c) {
return d(b, c) && e(b, c);
}
@Override
public @Nullable Object c(@Nullable Object d, TypeDescriptor e, TypeDescriptor f) {
if (d == null) {
return null;
}
@SuppressWarnings("unchecked")
Map<Object, Object> g = (Map<Object, Object>) d;
// Shortcut if possible...
boolean h = !f.getType().isInstance(d);
if (!h && g.isEmpty()) {
return g;
}
TypeDescriptor i = f.getMapKeyTypeDescriptor();
TypeDescriptor j = f.getMapValueTypeDescriptor();
List<MapEntry> k = new ArrayList<>(g.size());
for (Map.Entry<Object, Object> l : g.entrySet()) {
Object m = l.getKey();
Object n = l.getValue();
Object o = f(m, e, i);
Object p = g(n, e, j);
k.add(new MapEntry(o, p));
if (m != o || n != p) {
h = true;
}
}
if (!h) {
return g;
}
Map<Object, Object> q = CollectionFactory.createMap(f.getType(),
(i != null ? i.getType() : null), g.size());
for (MapEntry r : k) {
r.addToMap(q);
}
return q;
}
// internal helpers
private boolean d(TypeDescriptor s, TypeDescriptor t) {
return ConversionUtils.canConvertElements(s.getMapKeyTypeDescriptor(),
t.getMapKeyTypeDescriptor(), this.conversionService);
}
private boolean e(TypeDescriptor u, TypeDescriptor v) {
return ConversionUtils.canConvertElements(u.getMapValueTypeDescriptor(),
v.getMapValueTypeDescriptor(), this.conversionService);
}
private @Nullable Object f(Object w, TypeDescriptor x, @Nullable TypeDescriptor y) {
if (y == null) {
return w;
}
return this.conversionService.convert(w, x.getMapKeyTypeDescriptor(w), y);
}
private @Nullable Object g(Object z, TypeDescriptor A, @Nullable TypeDescriptor B) {
if (B == null) {
return z;
}
return this.conversionService.convert(z, A.getMapValueTypeDescriptor(z), B);
}
private static class MapEntry {
private final @Nullable Object key;
private final @Nullable Object value;
public MapEntry(@Nullable Object C, @Nullable Object D) {
this.key = C;
this.value = D;
}
public void a(Map<Object, Object> E) {
E.put(this.key, this.value);
}
}
}
Run 1
Despite clear structural organization and good use of line breaks, the code is severely undermined by meaningless names like 'a', 'b', 'c', 'd', 'e', 'f', 'g', and single-letter variables throughout. This makes intent nearly impossible to discern without deep analysis. The original context (method names like getConvertibleTypes, matches, convert) is lost. Nesting is moderate, but reading flow is damaged by opaque identifiers. Action granularity is otherwise reasonable, and the Javadoc helps, but the variable naming destroys clarity.
Run 2
This code is obfuscated and effectively unreadable. Identifiers are meaningless single letters (a, b, c, g, f), destroying clarity of intent and reading flow. Method names like a(), b(), c(), d(), e() give no indication of purpose. Parameter names such as 'b', 'c', 'd', 'e', 'f' are similarly unhelpful. This breaks action granularity and makes the logic extremely difficult to follow. While the code has some logical structure and is not deeply nested, the severe naming problems overshadow any structural merits. The original Spring Framework version of this class uses descriptive names like 'getConvertibleTypes', 'matches', 'convert', 'canConvertKey', 'canConvertValue', which makes the algorithm comprehensible. Here, the reader must reverse-engineer every variable and method, making maintenance and review error-prone.
Run 3
This code is nearly unreadable because it has been deliberately obfuscated. Every meaningful identifier (classes, methods, parameters, variables) is reduced to single letters like 'a', 'b', 'c', or 'd', destroying clarity of intent and reading flow. The method names 'a()', 'b()', 'c()', etc., give no indication of their purpose, and even the Javadoc cannot compensate. Nesting is moderate but the loss of semantic naming makes the logic difficult to follow. Structural organization is present (constructor, conversion method, helpers, inner class), but the obfuscated names nullify any benefit. Code length is concise, but this comes at the cost of severe ambiguity. Action granularity is acceptable, yet the meaningless names make it impossible to scan naturally. Overall, the code technically compiles and is formatted, but for a human reader it fails on all readability criteria.
Run 1
Code Structure: The converter, helper methods, and entry class are logically separated. Nesting: Shallow loops and early returns keep control flow manageable. Clarity of intent: Documentation explains the overall purpose, but single-letter method and variable names obscure source versus target types, conversion results, and copy decisions. The call to r.addToMap(q) does not match the entry class's declared method a, creating additional confusion. Code length: Reasonably concise for the conversion logic, with small helpers and limited duplication. Action granularity: Most lines perform one action, making individual operations easy to isolate. Reading flow: The sequence from validation through conversion to map creation is natural, but readers must repeatedly trace cryptic identifiers to understand it. Overall, sound structural formatting is substantially undermined by ambiguous naming and an inconsistent method reference.
Run 2
Code Structure: Logically organized into conversion logic, helper methods, and an entry class. Nesting: Shallow loops and conditionals, with early returns keeping complexity manageable. Clarity of intent: Class documentation explains the purpose, but single-letter method and variable names obscure source/target roles and conversion decisions. The call to addToMap also conflicts with the entry class's method named a, disrupting comprehension. Code length: Reasonably concise for the functionality, though separate key/value helpers introduce some repetition. Action granularity: Most lines perform one action, making individual statements easy to scan. Reading flow: Consistent formatting and a natural conversion sequence help, but readers must repeatedly trace ambiguous identifiers to understand data flow. Overall, sound organization is substantially undermined by naming and inconsistent method references.
Run 3
Code Structure: The class is logically divided into conversion logic, helper methods, and an entry wrapper. Nesting: Shallow loops and conditionals, with early returns, keep control flow manageable. Clarity of intent: Documentation explains the overall purpose, but single-letter method and variable names obscure source/target roles and conversion decisions. The call to addToMap does not match the wrapper's method a, further confusing intent. Code length: Reasonably concise, though temporary entry storage and several minimally named helpers add reading overhead. Action granularity: Most lines perform one action, making individual statements easy to parse. Reading flow: Formatting and method grouping support sequential reading, but opaque identifiers require repeated cross-referencing, substantially weakening readability.