Sample

int-80014ceb2bcd-I04

Replace method, parameter, and local names with deterministic ProGuard-style short identifiers

Matched original source

Lines143

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.7350–1; higher is more readable
Dorn0.7780–1; higher is more readable
Mi0.5650–1; higher is more readable
LLOC33Logical lines; fewer is more readable
DeepSeek V4 Pro50–20; mean of three runs
GPT-6.1 Sol100–20; mean of three runs
BTTF0.4150–1; higher is more readable

Views

Source code

package org.springframework.core; import java.lang.reflect.Method; import java.lang.reflect.Proxy; import java.util.LinkedHashMap; import java.util.LinkedHashSet; import java.util.Map; import java.util.Set; import org.jspecify.annotations.Nullable; import org.springframework.util.ClassUtils; import org.springframework.util.ReflectionUtils; /** * Defines the algorithm for searching for metadata-associated methods exhaustively * including interfaces and parent classes while also dealing with parameterized methods * as well as common scenarios encountered with interface and class-based proxies. * * <p>Typically, but not necessarily, used for finding annotated handler methods. * * @author Juergen Hoeller * @author Rossen Stoyanchev * @author Sam Brannen * @since 4.2.3 */ public final class MethodIntrospector { private MethodIntrospector() { } /** * Select methods on the given target type based on the lookup of associated metadata. * <p>Callers define methods of interest through the {@link MetadataLookup} parameter, * allowing to collect the associated metadata into the result map. * @param targetType the target type to search methods on * @param metadataLookup a {@link MetadataLookup} callback to inspect methods of interest, * returning non-null metadata to be associated with a given method if there is a match, * or {@code null} for no match * @return the selected methods associated with their metadata (in the order of retrieval), * or an empty map in case of no match */ public static <T> Map<Method, T> a(Class<?> a, final MetadataLookup<T> b) { final Map<Method, T> c = new LinkedHashMap<>(); Set<Class<?>> d = new LinkedHashSet<>(); Class<?> e = null; if (!Proxy.isProxyClass(a)) { e = ClassUtils.getUserClass(a); d.add(e); } d.addAll(ClassUtils.getAllInterfacesForClassAsSet(a)); for (Class<?> f : d) { final Class<?> g = (e != null ? e : f); ReflectionUtils.doWithMethods(f, method -> { Method h = ClassUtils.getMostSpecificMethod(method, g); T i = b.inspect(h); if (i != null) { Method j = BridgeMethodResolver.findBridgedMethod(h); if (j == h || j == method || j.equals(h) || j.equals(method) || b.inspect(j) == null) { c.put(h, i); } } }, ReflectionUtils.USER_DECLARED_METHODS); } return c; } /** * Select methods on the given target type based on a filter. * <p>Callers define methods of interest through the {@code MethodFilter} parameter. * @param targetType the target type to search methods on * @param methodFilter a {@code MethodFilter} to help * recognize handler methods of interest * @return the selected methods, or an empty set in case of no match */ public static Set<Method> a(Class<?> k, final ReflectionUtils.MethodFilter l) { return a(k, (MetadataLookup<Boolean>) method -> (l.matches(method) ? Boolean.TRUE : null)).keySet(); } /** * Select an invocable method on the target type: either the given method itself * if actually exposed on the target type, or otherwise a corresponding method * on one of the target type's interfaces or on the target type itself. * <p>Matches on user-declared interfaces will be preferred since they are likely * to contain relevant metadata that corresponds to the method on the target class. * @param method the method to check * @param targetType the target type to search methods on * (typically an interface-based JDK proxy) * @return a corresponding invocable method on the target type * @throws IllegalStateException if the given method is not invocable on the given * target type (typically due to a proxy mismatch) */ public static Method b(Method m, Class<?> n) { if (m.getDeclaringClass().isAssignableFrom(n)) { return m; } try { String o = m.getName(); Class<?>[] p = m.getParameterTypes(); for (Class<?> q : n.getInterfaces()) { try { return q.getMethod(o, p); } catch (NoSuchMethodException r) { // Alright, not on this interface then... } } // A final desperate attempt on the proxy class itself... return n.getMethod(o, p); } catch (NoSuchMethodException s) { throw new IllegalStateException(String.format( "Need to invoke method '%s' declared on target class '%s', " + "but not found in any interface(s) of the exposed proxy type. " + "Either pull the method up to an interface or switch to CGLIB " + "proxies by enforcing proxy-target-class mode in your configuration.", m.getName(), m.getDeclaringClass().getSimpleName())); } } /** * A callback interface for metadata lookup on a given method. * @param <T> the type of metadata returned */ @FunctionalInterface public interface MetadataLookup<T> { /** * Perform a lookup on the given method and return associated metadata, if any. * @param method the method to inspect * @return non-null metadata to be associated with a method if there is a match, * or {@code null} for no match */ @Nullable T a(Method t); } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.3758.09−124.017
Source linesThe number of non-empty source lines.143+57.2
Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value.4.929−7.394

Intercept 8.87 + feature contributions = -65.341 (log-odds).
Score = sigmoid(-65.341) = 0.

Score0.735

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.143−4.027
Indentation frequencyHow rapidly indentation changes from line to line.93+2.48
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.142.849+1.587
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.90.694+0.659
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.064+0.32
Identifier layout (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names.91.993−0.231

Intercept 0.07 + feature contributions = 1.255 (log-odds).
Score = sigmoid(1.255) = 0.778.

Score0.565
Score33
Run 1

The code structure is severely obfuscated by generic, meaningless variable names (a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t). Method names like 'a' and 'b' completely obscure intent. While the logical flow is not overly nested, the 'a' method contains dense conditional logic on a single line which requires significant mental parsing. The single-letter naming forces the reader to constantly map variables to their conceptual roles, destroying natural reading flow. Action granularity is acceptable, with one primary action per line, but clarity of intent is virtually nil. Although the original Javadocs help somewhat, they discuss intent but don't fix the identifiers. The code is concise but at the cost of total unreadability.

Run 2

The code is extremely unreadable due to single-character variable names (a, b, c, d, etc.) that are meaningless, making the logic nearly impossible to follow without the original names. The parameter names in methods, loops, and lambdas obscure intent, despite the presence of descriptive Javadoc. The structure is otherwise logical but the naming destroys clarity. Nesting is moderate, reading flow is disrupted by opaque identifiers, and the lambda body has multiple actions. Code length is reasonable but misleading because the cryptic names require constant mental mapping. The public API is unusable without reconstructed context from the documentation. Renaming variables to meaningful terms (targetType, metadataLookup, result, etc.) would dramatically improve readability. Action granularity is okay in most places but suffers from the same naming issues. Overall, it reads like obfuscated source code rather than maintainable Spring framework code.

Run 3

The code has severely obfuscated variable and method names (a, b, c, d, etc.) making it very hard to understand intent. While it has some positive aspects like flat nesting, reasonable method lengths, and single actions per line, the single-letter naming destroys clarity. The structure is logical but impossible to follow without significant mental mapping. Method names like 'a' and 'b' provide zero semantic meaning. The reading flow is disrupted by having to constantly backtrack to understand what each variable represents. Even with good Javadoc, the implementation is nearly unreadable as written. This appears to be intentionally obfuscated code that would need complete renaming to be maintainable.

Run 1

Code Structure: Distinct methods and a callback interface provide logical organization. Nesting: Moderate nesting in the method traversal lambda and nested exception handling adds complexity but remains manageable. Clarity of intent: Single-letter method and variable names severely obscure purpose; Javadoc helps, but its parameter names do not match the signatures. Calls to inspect also conflict with the callback's declared method a, disrupting comprehension. Code length: Implementation is reasonably concise, with extensive but useful documentation. Action granularity: Most lines perform one action, although the chained filter conversion and compound bridge-method condition require additional parsing. Reading flow: Consistent formatting, early returns, and ordered traversal support natural reading, but opaque identifiers and declaration inconsistencies repeatedly force readers to reconstruct meaning.

Run 2

Code Structure: Well-organized utility class with separate selection and invocation methods and a dedicated callback interface. Nesting: Moderate nesting in the method-processing lambda and interface search adds complexity but remains manageable. Clarity of intent: Single-letter method and variable names severely obscure roles; Javadoc helps, but parameter names do not match signatures, and calls to inspect conflict with the callback method named a. Code length: Implementation is reasonably concise for reflection and proxy handling, though extensive documentation increases reading overhead. Action granularity: Most lines perform one action; the compound bridge-method condition and chained filter expression require extra parsing. Reading flow: Consistent formatting and logical sequencing support navigation, but opaque identifiers force repeated cross-referencing, interrupting otherwise natural flow.

Run 3

Code Structure: Distinct utility methods and a callback interface provide logical organization. Nesting: Moderate nesting in the method-selection lambda and interface-search exception handling increases effort but remains manageable. Clarity of intent: Single-letter method and variable names severely obscure purpose; Javadocs help, but parameter names do not match the signatures. Calls to inspect also conflict with the callback's declared method a, making the intended API confusing. Code length: Implementation is reasonably concise, though extensive documentation outweighs the code. Action granularity: Most lines perform one action; the filter overload combines casting, a lambda, delegation, and result extraction into one expression. Reading flow: Consistent formatting and sensible sequencing support navigation, but opaque identifiers and a compound bridge-method condition repeatedly interrupt comprehension.