Sample

int-7e1a39c53da0-SRC

Unmodified source class

Lines143

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.660–1; higher is more readable
Dorn0.6970–1; higher is more readable
Mi0.170–1; higher is more readable
LLOC33Logical lines; fewer is more readable
DeepSeek V4 Pro170–20; mean of three runs
GPT-6.1 Sol170–20; mean of three runs
BTTF0.5140–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) { final Class<?> targetClass = (specificHandlerType != null ? specificHandlerType : currentHandlerType); ReflectionUtils.doWithMethods(currentHandlerType, method -> { Method specificMethod = ClassUtils.getMostSpecificMethod(method, targetClass); 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.3736.929−123.319
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.376

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

Score0.66

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.912+1.588
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.111.986−1.078
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.111.965+1.002
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.056+0.398
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = 0.831 (log-odds).
Score = sigmoid(0.831) = 0.697.

Score0.17
Score33
Run 1

The code is well-structured and readable. It uses clear method names, Javadoc, and logical organization. Nesting is moderate; the main method has a loop with a callback but remains understandable. The bridge method resolution condition is complex and somewhat ambiguous, slightly reducing clarity of intent. Code length is appropriate, and action granularity is mostly one action per line. Reading flow is natural due to the top-down structure and explanatory comments. Overall, it is highly readable with minor complexity in the bridge method condition.

Run 2

The code is well-structured with clear class-level organization, separate methods, and Javadoc for public APIs. Nesting is moderate—the lambda inside a loop inside a method is acceptable, but the bridge-method condition is somewhat dense and hard to parse at a glance. Intent is mostly clear from method names and comments, though the bridge-method logic lacks explanatory comments. Code length is reasonable, but some conditions could be extracted into helper methods for clarity. Action granularity is mostly one action per line, but the long conditional and `String.format` block add slight noise. Reading flow is generally natural: class definition, methods in logical order, and helper interface at the end. Minor issues: the empty `catch` block is acceptable here but slightly unusual, and the `selectMethods` method has multiple responsibilities (type resolution, filtering, mapping). Overall, very readable with only small readability improvements possible.

Run 3

The code is well-structured and highly readable overall. It follows a logical organization with clear separation of concerns, minimal nesting, and concise method bodies. Intent is clearly communicated through meaningful method names and solid Javadoc. Each line generally performs one action, and the reading flow is natural. The only notable issue is the bridge method resolution condition in selectMethods, which is somewhat dense and potentially ambiguous, slightly reducing clarity. Additionally, the inner lambda and multi-condition boolean expression increase cognitive load, but not excessively. Overall, the code is maintainable and clear.

Run 1

Code Structure: Well-organized utility class with focused methods, a delegating overload, and a clearly separated callback interface. Nesting: Mostly manageable, although the loop/lambda/conditional combination and nested exception handling add complexity. Clarity of intent: Descriptive method names and thorough Javadoc explain the purpose; the bridge-method condition is technically dense and lacks an explanation of its rationale. Code length: Implementation is reasonably concise for reflection and proxy handling, though documentation adds substantial length. Action granularity: Most statements perform one action; the filter overload compresses casting, lambda logic, delegation, and result extraction into one expression. Reading flow: Consistent formatting, early return, and logical search progression support natural reading, with minor friction from the compound condition and exception-driven interface lookup.

Run 2

Code Structure: Logically organized into focused utility methods and a clearly defined callback interface. Nesting: Mostly manageable, but the loop/lambda/conditional combination in metadata selection and nested try blocks in invocable-method lookup require extra attention. Clarity of intent: Descriptive method names and thorough Javadoc explain the purpose well; bridge-method comparisons and reflection-specific behavior are less immediately intuitive. Code length: Implementation is reasonably concise for its responsibilities, though documentation is extensive and the compound bridge-method condition is dense. Action granularity: Most statements perform one action; the filter overload combines adaptation, delegation, and key-set extraction in one expression. Reading flow: Consistent formatting and logical progression make the code easy to follow, with minor interruptions from long conditions, exception-driven lookup, and specialized proxy terminology.

Run 3

Code Structure: Cohesive utility class with clearly separated selection methods and a small callback interface. Nesting: Generally manageable, though the loop/lambda/conditional combination and nested try blocks require extra attention. Clarity of intent: Descriptive method names and thorough Javadoc explain the API well; the compound bridge-method condition and abbreviated 'ifc' variable are less immediately clear. Code length: Implementation is reasonably concise and reuses the metadata-based selector, although documentation and the exception message increase overall length. Action granularity: Most statements perform one action; the filter overload combines casting, a lambda, a ternary, delegation, and key extraction in one expression. Reading flow: Consistent formatting and orderly setup, traversal, and return paths support natural reading, with reflection-specific logic and exception-driven interface searching introducing some friction.