Source code
package org.springframework.http;
import java.util.AbstractMap.SimpleImmutableEntry;
import java.util.Collections;
import java.util.LinkedHashSet;
import java.util.List;
import java.util.Map;
import java.util.Map.Entry;
import java.util.Set;
import java.util.function.BiConsumer;
import java.util.stream.Collectors;
import org.jspecify.annotations.Nullable;
import org.springframework.util.CollectionUtils;
import org.springframework.util.MultiValueMap;
/**
* {@code HttpHeaders} variant that can only be read, not written to.
*
* <p>This caches the parsed representations of the "Accept" and "Content-Type"
* headers and will get out of sync with the backing map if it is mutated at runtime.
*
* @author Brian Clozel
* @author Sam Brannen
* @since 5.1.1
*/
class ReadOnlyHttpHeaders extends HttpHeaders {
private static final long serialVersionUID = -8578554704772377436L;
private @Nullable MediaType cachedContentType;
@SuppressWarnings("serial")
private @Nullable List<MediaType> cachedAccept;
ReadOnlyHttpHeaders(MultiValueMap<String, String> hea) {
super(hea);
}
@Override
public @Nullable MediaType get2() {
if (this.cachedContentType != null) {
return this.cachedContentType;
}
else {
MediaType content = super.getContentType();
this.cachedContentType = content;
return content;
}
}
@Override
public List<MediaType> get3() {
if (this.cachedAccept != null) {
return this.cachedAccept;
}
else {
List<MediaType> acc = super.getAccept();
this.cachedAccept = acc;
return acc;
}
}
@Override
public void clear2() {
// No-op.
}
@Override
public @Nullable List<String> get(String header) {
List<String> val = this.headers.get(header);
return (val != null ? Collections.unmodifiableList(val) : null);
}
@Override
public void add(String header2, @Nullable String header3) {
throw new UnsupportedOperationException();
}
@Override
public void add2(String key, List<? extends String> header4) {
throw new UnsupportedOperationException();
}
@Override
public void add2(HttpHeaders val2) {
throw new UnsupportedOperationException();
}
@Override
public void set(String header5, @Nullable String header6) {
throw new UnsupportedOperationException();
}
@Override
public void set2(Map<String, String> val3) {
throw new UnsupportedOperationException();
}
@Override
public Map<String, String> to() {
return Collections.unmodifiableMap(this.headers.toSingleValueMap());
}
@SuppressWarnings("removal")
@Override
@Deprecated(since = "7.0", forRemoval = true)
public Map<String, String> as() {
return Collections.unmodifiableMap(this.headers.asSingleValueMap());
}
@SuppressWarnings("removal")
@Override
@Deprecated(since = "7.0", forRemoval = true)
public MultiValueMap<String, String> as2() {
return CollectionUtils.unmodifiableMultiValueMap(this.headers);
}
@Override
public Set<String> header() {
return Collections.unmodifiableSet(super.headerNames());
}
@Override
public List<String> put(String key, List<String> val4) {
throw new UnsupportedOperationException();
}
@Override
public @Nullable List<String> put2(String header7, List<String> header8) {
throw new UnsupportedOperationException();
}
@Override
public void put3(@Nullable HttpHeaders val5) {
throw new UnsupportedOperationException();
}
@Override
public void put3(Map<? extends String, ? extends List<String>> hea2) {
throw new UnsupportedOperationException();
}
@Override
public List<String> rem(String key) {
throw new UnsupportedOperationException();
}
@Override
public void cle() {
throw new UnsupportedOperationException();
}
@Override
public Set<Entry<String, List<String>>> header2() {
return super.headerSet().stream().map(SimpleImmutableEntry::new)
.collect(Collectors.collectingAndThen(
Collectors.toCollection(LinkedHashSet::new), // Retain original ordering of entries
Collections::unmodifiableSet));
}
@Override
public void for2(BiConsumer<? super String, ? super List<String>> act) {
for (String nam : this.headers.keySet()) {
List<String> val6 = this.headers.get(nam);
act.accept(nam, (val6 != null ? Collections.unmodifiableList(val6) : Collections.emptyList()));
}
}
}
Run 1
The code has a clear high-level purpose (read-only HttpHeaders) and follows a consistent structural pattern, but readability is severely harmed by poor naming and abbreviated identifiers. Method names like get2(), get3(), add2(), set2(), put2(), put3(), for2(), to(), as(), and header2() obscure intent and make the API difficult to understand without external documentation. Parameter names (hea, header2, header3, val2, etc.) are similarly uninformative. The nesting is shallow and actions are generally one per line, which is positive, but the abbreviation of method names negates much of that benefit. The code length is reasonable and the reading flow is logical within each method, but the cumulative effect of cryptic names makes the class feel disorganized. Overall, the structure is acceptable for experienced developers familiar with Spring internals, but the naming choices significantly reduce clarity and maintainability.
Run 2
The code suffers from severely degraded readability due to obfuscated naming (e.g., get2, add2, put3, val2, header5, hea2), which obscures intent and breaks reading flow. Method names do not reflect their actual behavior (e.g., clear2 is a no-op). The structure is logical but weakened by redundant override methods that only throw UnsupportedOperationException. Nesting is acceptable, and action granularity is mostly one operation per line. However, clarity of intent is very low because parameter and method names are meaningless, likely the result of decompilation or deliberate obfuscation. Overall, the code is maintainable only with significant renaming and cleanup.
Run 3
The code is functionally organized but has poor readability due to vague method names like get2, add2, put3, rem, cle, for2, and header2; these make intent unclear. Naming inconsistencies (hea, val2, header3, etc.) add confusion. The class purpose is documented, but methods are not. Nesting is mostly flat, and lines are concise, but the overall reading flow suffers from ambiguous identifiers and repetitive boilerplate. Some methods group multiple actions, and the use of unclear parameters reduces clarity of intent. The structure is logical but obfuscated by unclear naming. Score reflects a mix of good organization (5-6) with poor naming and clarity (2-3).
Run 1
Code Structure: Methods are logically separated, with caching accessors followed mainly by read-only wrappers and blocked mutations. Nesting: Shallow conditionals and one simple loop make control flow easy to follow. Clarity of intent: The class documentation clearly explains its read-only purpose and caching caveat, but names such as get2, as2, put3, hea, and val6 obscure individual operations. Code length: Most methods are concise; repeated exception-throwing overrides add length but support the read-only design. Action granularity: Statements generally perform one action per line, although the stream pipeline and inline conditional arguments require more interpretation. Reading flow: Consistent formatting and annotations help navigation, but cryptic naming, repetitive overrides, and the less direct stream expression interrupt otherwise straightforward reading.
Run 2
Code Structure: The class is logically organized around cached reads, unmodifiable views, and rejected mutations, with small, separated methods. Nesting: Mostly flat, with only simple conditionals and one loop; the collector expression is slightly harder to parse. Clarity of intent: Class documentation explains the read-only purpose and caching caveat, but names such as get2, as2, put3, hea, and val6 obscure individual operations and parameter meanings. Code length: Most methods are concise; repeated exception-throwing overrides add length but fit the wrapper design. Redundant else blocks and generous blank spacing add minor overhead. Action granularity: Statements generally perform one action each, although chained stream operations and inline conditional arguments compress several concepts. Reading flow: Consistent formatting and annotations support scanning, but cryptic, numbered method names force readers to inspect implementations or consult the superclass to understand the API.
Run 3
Code Structure: The class is logically organized around cached reads, read-only views, and rejected mutations, though method grouping could be clearer. Nesting: Most methods are flat, with only shallow conditionals and one loop; the collector expression adds modest complexity. Clarity of intent: Class documentation clearly explains the read-only purpose and caching limitation, but cryptic names such as get2, as2, put3, hea, and val6 significantly obscure individual operations. Code length: Methods are concise; repeated exception-throwing overrides add length but fit the wrapper design. Action granularity: Statements generally perform one action per line, although chained stream operations and inline ternaries combine several transformations. Reading flow: Consistent formatting and straightforward implementations help, but numbered method names, weak parameter names, and the contrast between a no-op clear2 and exception-throwing cle interrupt natural comprehension.