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> a) {
super(a);
}
@Override
public @Nullable MediaType a() {
if (this.cachedContentType != null) {
return this.cachedContentType;
}
else {
MediaType b = super.getContentType();
this.cachedContentType = b;
return b;
}
}
@Override
public List<MediaType> b() {
if (this.cachedAccept != null) {
return this.cachedAccept;
}
else {
List<MediaType> c = super.getAccept();
this.cachedAccept = c;
return c;
}
}
@Override
public void c() {
// No-op.
}
@Override
public @Nullable List<String> d(String d) {
List<String> e = this.headers.get(d);
return (e != null ? Collections.unmodifiableList(e) : null);
}
@Override
public void e(String f, @Nullable String g) {
throw new UnsupportedOperationException();
}
@Override
public void f(String h, List<? extends String> i) {
throw new UnsupportedOperationException();
}
@Override
public void f(HttpHeaders j) {
throw new UnsupportedOperationException();
}
@Override
public void g(String k, @Nullable String l) {
throw new UnsupportedOperationException();
}
@Override
public void h(Map<String, String> m) {
throw new UnsupportedOperationException();
}
@Override
public Map<String, String> i() {
return Collections.unmodifiableMap(this.headers.toSingleValueMap());
}
@SuppressWarnings("removal")
@Override
@Deprecated(since = "7.0", forRemoval = true)
public Map<String, String> j() {
return Collections.unmodifiableMap(this.headers.asSingleValueMap());
}
@SuppressWarnings("removal")
@Override
@Deprecated(since = "7.0", forRemoval = true)
public MultiValueMap<String, String> k() {
return CollectionUtils.unmodifiableMultiValueMap(this.headers);
}
@Override
public Set<String> l() {
return Collections.unmodifiableSet(super.headerNames());
}
@Override
public List<String> m(String n, List<String> o) {
throw new UnsupportedOperationException();
}
@Override
public @Nullable List<String> n(String p, List<String> q) {
throw new UnsupportedOperationException();
}
@Override
public void o(@Nullable HttpHeaders r) {
throw new UnsupportedOperationException();
}
@Override
public void o(Map<? extends String, ? extends List<String>> s) {
throw new UnsupportedOperationException();
}
@Override
public List<String> p(String t) {
throw new UnsupportedOperationException();
}
@Override
public void q() {
throw new UnsupportedOperationException();
}
@Override
public Set<Entry<String, List<String>>> r() {
return super.headerSet().stream().map(SimpleImmutableEntry::new)
.collect(Collectors.collectingAndThen(
Collectors.toCollection(LinkedHashSet::new), // Retain original ordering of entries
Collections::unmodifiableSet));
}
@Override
public void s(BiConsumer<? super String, ? super List<String>> u) {
for (String v : this.headers.keySet()) {
List<String> w = this.headers.get(v);
u.accept(v, (w != null ? Collections.unmodifiableList(w) : Collections.emptyList()));
}
}
}
Run 1
The code demonstrates poor readability due to heavily obfuscated naming (single letters like a(), b(), d(), e(), etc.) that obscures method intent. While the class structure is logical and nesting is flat, the clarity of intent is severely compromised—readers must infer method purposes from context rather than names. Code length is concise, but action granularity varies: some methods chain multiple operations on one line (e.g., return statements), while others are appropriately granular. Reading flow is disrupted by inconsistent naming and lack of descriptive identifiers, despite the clear ordering of methods. The comments and annotations are helpful, but the non-descriptive method and variable names make this code hard to maintain and understand without external documentation. Overall, it reads like obfuscated code rather than self-documenting clean code.
Run 2
The code suffers from severe readability issues. Most method and parameter names are single letters (a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, u, v, w), making intent completely opaque without deep knowledge of the superclass. This violates clarity of intent and reading flow. While the structure follows a predictable pattern (read methods vs throw UnsupportedOperationException), the excessive use of meaningless identifiers makes it hard to understand what each method does. Nesting is acceptable but not a strength. The caching logic in a() and b() is straightforward but obscured by names. Action granularity is mostly one action per line, but the point is moot when actions lack semantic labels. This appears to be obfuscated code, possibly decompiled or intentionally stripped for an exercise. Even the import of SimpleImmutableEntry is misused for a set of entries. The code length is reasonable given the class purpose, but conciseness is undermined by lack of meaningful context. A reader cannot easily map methods to HttpHeaders API.
Run 3
The code structure is logical but severely obfuscated by meaningless method and variable names (a(), b(), c(), d, e, f...). The intent of each override is unclear—readers must infer functionality from the throw statements, return types, or context. Nesting is shallow, which is good, and each action is generally on a single line. However, the method signatures hide the actual operations (e.g., getContentType() is renamed a()), making the reading flow unnatural and forcing constant lookup of the parent class to understand each method's purpose. The use of unclear naming, even for local variables (e.g., 'a', 'b', 'c', 'd', 'e'), further reduces clarity. While the class structure and formatting are clean, the lack of descriptive naming makes it effectively unreadable without intense effort. The code length is appropriate but the unnecessary opacity makes it feel longer and more difficult to parse. Overall, maintainability is poor.
Run 1
Code Structure: The class is logically organized into small overrides, with caching and read-only wrappers clearly separated. Nesting: Control flow is shallow, limited to simple conditionals and one loop; the collector expression is slightly harder to parse. Clarity of intent: The class documentation and descriptive cache fields explain the overall purpose, but single-letter method, parameter, and local variable names severely 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 stream chaining and inline ternaries compress several operations. Reading flow: Consistent formatting and annotations help navigation, but opaque names, overloaded single-letter methods, and dependence on superclass behavior interrupt understanding.
Run 2
Code Structure: The class is logically organized into small overrides, with caching, read-only access, and rejected mutations consistently implemented. Nesting: Shallow conditionals and a simple loop are easy to follow; the stream collector is slightly denser. Clarity of intent: Class documentation and descriptive cache fields explain the overall purpose, but single-letter method and parameter names severely obscure individual operations and force readers to inspect implementations. Code length: Mostly concise, although repeated exception-only overrides add bulk and caching branches could be simplified. Action granularity: Statements generally perform one action per line; the stream pipeline combines several transformations but remains reasonably formatted. Reading flow: Consistent annotations, spacing, and implementation patterns help navigation, but opaque names and alternating accessor/mutator methods prevent a fully natural reading experience.
Run 3
Code Structure: The class is logically organized into short overrides, with consistent formatting and a helpful class-level explanation. Nesting: Control flow is shallow, limited to simple conditionals and one loop; the stream expression is somewhat harder to parse. Clarity of intent: Descriptive class and cache names reveal the overall purpose, but single-letter method names, parameters, and locals severely obscure individual operations and force readers to infer meaning from implementation details. Code length: Most methods are concise; repeated exception-throwing overrides add length but fit the read-only design. Action granularity: Statements generally perform one action per line, although the stream pipeline combines several transformations. Reading flow: Consistent layout and repeated patterns support scanning, but opaque naming and the dense collector expression interrupt comprehension.