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 conversion) {
this.conversionService = conversion;
}
@Override
public Set<ConvertiblePair> get() {
return Collections.singleton(new ConvertiblePair(Map.class, Map.class));
}
@Override
public boolean mat(TypeDescriptor source2, TypeDescriptor target) {
return can(source2, target) && can2(source2, target);
}
@Override
public @Nullable Object con(@Nullable Object sou, TypeDescriptor source, TypeDescriptor target2) {
if (sou == null) {
return null;
}
@SuppressWarnings("unchecked")
Map<Object, Object> source3 = (Map<Object, Object>) sou;
// Shortcut if possible...
boolean copy = !target2.getType().isInstance(sou);
if (!copy && source3.isEmpty()) {
return source3;
}
TypeDescriptor key2 = target2.getMapKeyTypeDescriptor();
TypeDescriptor value2 = target2.getMapValueTypeDescriptor();
List<MapEntry> target3 = new ArrayList<>(source3.size());
for (Map.Entry<Object, Object> ent : source3.entrySet()) {
Object source4 = ent.getKey();
Object source5 = ent.getValue();
Object target4 = convert(source4, source, key2);
Object target5 = convert2(source5, source, value2);
target3.add(new MapEntry(target4, target5));
if (source4 != target4 || source5 != target5) {
copy = true;
}
}
if (!copy) {
return source3;
}
Map<Object, Object> target6 = CollectionFactory.createMap(target2.getType(),
(key2 != null ? key2.getType() : null), source3.size());
for (MapEntry ent2 : target3) {
ent2.addToMap(target6);
}
return target6;
}
// internal helpers
private boolean can(TypeDescriptor source6, TypeDescriptor target7) {
return ConversionUtils.canConvertElements(source6.getMapKeyTypeDescriptor(),
target7.getMapKeyTypeDescriptor(), this.conversionService);
}
private boolean can2(TypeDescriptor source7, TypeDescriptor target8) {
return ConversionUtils.canConvertElements(source7.getMapValueTypeDescriptor(),
target8.getMapValueTypeDescriptor(), this.conversionService);
}
private @Nullable Object convert(Object source8, TypeDescriptor source9, @Nullable TypeDescriptor target9) {
if (target9 == null) {
return source8;
}
return this.conversionService.convert(source8, source9.getMapKeyTypeDescriptor(source8), target9);
}
private @Nullable Object convert2(Object source10, TypeDescriptor source11, @Nullable TypeDescriptor target10) {
if (target10 == null) {
return source10;
}
return this.conversionService.convert(source10, source11.getMapValueTypeDescriptor(source10), target10);
}
private static class MapEntry {
private final @Nullable Object key;
private final @Nullable Object value;
public MapEntry(@Nullable Object key, @Nullable Object val) {
this.key = key;
this.value = val;
}
public void add(Map<Object, Object> map) {
map.put(this.key, this.value);
}
}
}
Run 1
The code has logical structure with helper methods and a clear class purpose, but readability is damaged by poor naming and inconsistencies. Method names like 'can', 'can2', 'convert', 'convert2', 'mat', 'con', and variables 'source2', 'target2', 'source3', 'source4' etc. obscure intent, making the reader work hard to understand what each represents. Nesting is low, but action granularity suffers from multi-step conversions packed into single lines. The MapEntry helper adds abstraction but its method 'add' is vague. The code is not overly long, yet the inconsistent naming pattern and abbreviations make the reading flow disjointed. Code structure exists but clarity of intent is severely undermined by ambiguous identifiers.
Run 2
The code has severe readability issues due to obfuscated naming conventions. Method names like mat(), can(), can2(), con(), and convert2() are cryptic and fail to convey intent, making the code ambiguous and difficult to understand without deep investigation. Variable names such as source2, target2, source3, target3, source4, target4, etc., are non-descriptive and create confusion about their roles. This significantly hurts clarity of intent and reading flow. While the code structure is linear and nesting is shallow, the action granularity is partially preserved, and helper methods exist, the overall readability is undermined by poor naming. The Javadoc on the class is helpful, but the obfuscated method and variable names override that benefit. The code length is moderate but the naming makes it feel longer and more complex than necessary.
Run 3
The code structure is logical but severely obfuscated by meaningless variable names like 'source2', 'target3', 'convert2', and 'can2'. Nesting is moderate, but the intent is difficult to discern due to non-descriptive method and variable names. The code length is reasonable but suffers from poor action granularity and reading flow, which feel disjointed due to the naming scheme. The helper methods and inner class are concise, but unnecessary renaming ('addToMap' vs 'add') adds confusion. Overall, the readability is significantly hindered by unclear naming and inconsistent terminology, making it difficult to follow the conversion logic.
Run 1
Code Structure: Logically separates conversion, compatibility checks, and entry storage into methods and a small nested class. Nesting: Shallow loops and conditionals, with early returns keeping complexity manageable. Clarity of intent: Documentation explains the overall purpose, but abbreviated method names and numbered variables obscure key/value roles. The addToMap call does not match the declared add method, further disrupting understanding. Code length: Reasonably compact for its functionality, though similar helpers introduce some repetition. Action granularity: Generally one action per line, with clearly separated assignments and conversions. Reading flow: The main conversion proceeds naturally from validation through transformation to map creation, but opaque identifiers require frequent backtracking to determine what each object represents.
Run 2
Code Structure: Responsibilities are logically separated into conversion, compatibility checks, and an entry helper. Nesting: Shallow loops and early returns keep control flow manageable. Clarity of intent: Documentation explains the purpose, but abbreviated methods and numbered variables obscure key/value and source/target roles. The call to addToMap does not match the helper's add method, and overridden method names appear inconsistent with the interface, undermining comprehension. Code length: Reasonably concise, although similar key/value helpers and intermediate entry storage add some overhead. Action granularity: Most lines perform a single clear operation. Reading flow: The conversion proceeds naturally from validation through element conversion to map creation, but cryptic naming forces repeated backtracking.
Run 3
Code Structure: Logical separation into conversion logic, helper methods, and an entry class supports readability. Nesting: Shallow loops and guard clauses keep control flow manageable. Clarity of intent: Documentation explains the purpose, but abbreviated method names and numbered variables obscure key/value and source/target roles. The call to addToMap does not match the defined add method, creating additional confusion. Code length: Reasonably compact, though similar helper methods and intermediate entry storage add some reading overhead. Action granularity: Most lines perform a single action, making individual operations easy to follow. Reading flow: Conversion proceeds in a sensible order from null handling through conversion to map creation, but readers must repeatedly decode vague identifiers and navigate helpers to understand details.