Sample

int-9f7c88500724-I12

Inline all eligible single-use intermediate local variables

Matched original source

Lines143

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.6540–1; higher is more readable
Dorn0.4920–1; higher is more readable
Mi0.170–1; higher is more readable
LLOC32Logical lines; fewer is more readable
DeepSeek V4 Pro15.670–20; mean of three runs
GPT-6.1 Sol160–20; mean of three runs
BTTF0.4820–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> selectMethods(Class<?> targetType, final MetadataLookup<T> metadataLookup) { final Map<Method, T> methodMap = new LinkedHashMap<>(); Set<Class<?>> handlerTypes = new LinkedHashSet<>(); Class<?> specificHandlerType = null; if (!Proxy.isProxyClass(targetType)) { specificHandlerType = ClassUtils.getUserClass(targetType); handlerTypes.add(specificHandlerType); } handlerTypes.addAll(ClassUtils.getAllInterfacesForClassAsSet(targetType)); for (Class<?> currentHandlerType : handlerTypes) { ReflectionUtils.doWithMethods(currentHandlerType, method -> { Method specificMethod = ClassUtils.getMostSpecificMethod(method, ((specificHandlerType != null ? specificHandlerType : currentHandlerType))); T result = metadataLookup.inspect(specificMethod); if (result != null) { Method bridgedMethod = BridgeMethodResolver.findBridgedMethod(specificMethod); if (bridgedMethod == specificMethod || bridgedMethod == method || bridgedMethod.equals(specificMethod) || bridgedMethod.equals(method) || metadataLookup.inspect(bridgedMethod) == null) { methodMap.put(specificMethod, result); } } }, ReflectionUtils.USER_DECLARED_METHODS); } return methodMap; } /** * 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> selectMethods(Class<?> targetType, final ReflectionUtils.MethodFilter methodFilter) { return selectMethods(targetType, (MetadataLookup<Boolean>) method -> (methodFilter.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 selectInvocableMethod(Method method, Class<?> targetType) { if (method.getDeclaringClass().isAssignableFrom(targetType)) { return method; } try { String methodName = method.getName(); Class<?>[] parameterTypes = method.getParameterTypes(); for (Class<?> ifc : targetType.getInterfaces()) { try { return ifc.getMethod(methodName, parameterTypes); } catch (NoSuchMethodException ex) { // Alright, not on this interface then... } } // A final desperate attempt on the proxy class itself... return targetType.getMethod(methodName, parameterTypes); } catch (NoSuchMethodException ex) { 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.", method.getName(), method.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 inspect(Method method); } }

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.3682.278−121.515
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.917−7.375

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

Score0.654

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 (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names.144.958−2.475
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.142.911+1.588
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.144.986+1.535
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.056+0.399
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = -0.032 (log-odds).
Score = sigmoid(-0.032) = 0.492.

Score0.17
Score32
Run 1

The code is well-structured with clear separation of concerns, a private constructor for a utility class, and comprehensive Javadoc. The complexity in selectMethods is high due to bridge method resolution logic, but it's broken into smaller conditional chunks and the surrounding comments aid understanding. Nesting is moderate: loops and lambdas create depth, but the one-action-per-line style keeps it manageable. Intent is explicit through named methods and callbacks. Some lines are long, especially the bridgedMethod condition with multiple ORs, which slightly reduces readability. selectInvocableMethod is clearly written with a flat structure and descriptive comments. Overall, the code is maintainable and readable for experienced developers, though a novice might find the bridge-method condition challenging.

Run 2

The code is generally well-structured and readable. The class has a clear single purpose, and methods are organized logically with descriptive Javadoc. However, readability suffers in a few areas. The `selectMethods` method contains a lambda with a deeply nested conditional (a chain of || conditions) that combines bridge method resolution logic, making the intent harder to grasp at a glance. The `selectInvocableMethod` method has a nested try-catch inside an outer try-catch, adding complexity. There is also a stray blank line with only whitespace. While the code is concise, some expressions—especially the inline ternary inside `getMostSpecificMethod`—mix multiple actions in one line. Overall the structure is good, but the bridge-method logic and nested exception handling slightly reduce clarity and flow.

Run 3

The code is generally well-structured with clear class and method boundaries, good Javadoc, and descriptive names. Methods are broken into logical units, and there is a reasonable attempt at flat structure. However, readability is reduced by the complex conditional in `selectMethods`—the multi-line `if` condition with five boolean checks is dense and hard to parse. The lambda inside `doWithMethods` adds nesting and obscures intent. The `selectInvocableMethod` has multiple try-catch blocks and relies on exception flow for logic, which makes the reading flow less natural. Some lines, like the `getMostSpecificMethod` call, are long and combine multiple actions, reducing action granularity. Overall, the code is maintainable but would benefit from extracting conditions into named variables or methods, and simplifying exception-based control flow.

Run 1

Code Structure: Well-organized utility class with focused methods and a clearly defined callback interface. Nesting: Mostly moderate, but the loop/lambda/nested-condition combination and nested try-catch blocks require extra attention. Clarity of intent: Descriptive names and thorough Javadoc explain the purpose; bridge-method comparisons and proxy handling are less immediately clear. Code length: Implementation is reasonably concise, although extensive documentation and extra blank lines increase visual length. Action granularity: Most statements perform one action, but chained calls, an inline ternary, and a multi-part Boolean condition concentrate several decisions into single expressions. Reading flow: Method ordering and early returns support natural progression, while the long getMostSpecificMethod expression, redundant parentheses, and exception-driven interface search interrupt the flow.

Run 2

Code Structure: Well-organized utility class with focused methods, a reusable overload, and a clearly separated callback interface. Nesting: Mostly moderate, though the loop/lambda/nested-condition combination and nested exception handling require extra attention. Clarity of intent: Descriptive names and thorough Javadocs explain the purpose; the bridge-method condition and inline type-selection expression are harder to interpret without domain knowledge. Code length: Implementation is reasonably concise, with substantial but useful documentation; redundant parentheses and stray blank lines add minor clutter. Action granularity: Most lines perform one action, although chained calls and compound conditions compress several decisions. Reading flow: Method ordering and early returns support natural progression, but long expressions and exception-driven interface searching interrupt the flow.

Run 3

Code Structure: Well-organized utility class with focused methods, a reusable overload, and a clearly separated callback interface. Nesting: Mostly moderate, but the loop/lambda/conditional combination and nested exception handling require extra attention. Clarity of intent: Descriptive names and thorough Javadocs explain the public API; the bridge-method condition and proxy-resolution details are harder to understand without domain knowledge. Code length: Implementation is reasonably concise, though documentation is extensive and some expressions are unnecessarily long. Action granularity: Most lines perform one action, but the inline ternary, callback delegation, and compound condition compress several decisions. Reading flow: Method ordering and consistent formatting support natural reading; redundant parentheses, stray blank space, and the lengthy bridge-method predicate interrupt it.