Sample

int-bb3a6731dbd5-I11

Split eligible integer literals into pairs of short-named intermediate variables

Matched original source

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 Pro17.330–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 highly readable. It has a clear, logical organization with a private constructor enforcing utility class semantics. Javadoc comments are comprehensive and explain intent. Nesting is controlled: the main selectMethods method uses a single for-loop and a lambda, avoiding deep indentation. The selectInvocableMethod has a try-catch with a nested try-catch inside a loop, but it is handled cleanly with explanatory comments. Intent is clear from method and variable names. Code length is concise; the bridge method resolution condition is complex but unavoidable for the domain. Each line performs a single logical action, improving clarity. Reading flow is natural, moving from broad utility methods to specific lookup logic. Overall, this is an excellent example of readable Spring framework code.

Run 2

The code is well-structured into clear methods with descriptive names, strong Javadoc, and logical separation of concerns. Nesting is minimal except in the bridge-method condition, which is slightly dense but still readable. Intent is clearly expressed through method and variable names like selectInvocableMethod and metadataLookup. The code is concise, avoids unnecessary verbosity, and generally maintains one action per line. Reading flow is natural, with the main algorithm in selectMethods flowing from type discovery to method iteration to metadata matching. The nested try/catch in selectInvocableMethod adds a bit of complexity but is handled with explanatory comments. Overall, this is professional, maintainable code with only minor readability challenges in the longest conditional.

Run 3

The code is well-structured and readable. It uses clear class and method names, concise Javadoc comments explaining intent, and a logical organization with a private constructor for a utility class. Nesting is generally shallow, though the first method contains a nested conditional with a multi-line boolean expression that is somewhat dense. Action granularity is mostly one action per line, and reading flow is natural. The main readability drawback is the complex bridge-method resolution condition, which requires careful reading to understand its purpose. Overall, the code is clear, maintainable, and follows Java conventions.

Run 1

Code Structure: Well-organized utility class with focused methods, a delegating overload, and a clearly defined callback interface. Nesting: Mostly moderate, but the loop/lambda/conditional combination and nested try/catch blocks increase cognitive load. Clarity of intent: Descriptive names and thorough Javadoc explain the API well; the compound bridge-method condition requires specialized knowledge and lacks a rationale comment. Code length: Implementation is reasonably concise; documentation is extensive but useful. Action granularity: Statements generally perform one action each, although the filter overload compresses casting, adaptation, selection, and key extraction into one expression. Reading flow: Consistent formatting, logical method order, and an early return support natural reading. Reflection and proxy-handling details introduce unavoidable complexity, while the abbreviated variable 'ifc' and dense boolean condition slightly reduce readability.

Run 2

Code Structure: Logically organized utility class with focused methods and a clearly separated callback interface. Nesting: Mostly manageable, though the loop/lambda/conditional sequence in selectMethods and nested try blocks in selectInvocableMethod require extra attention. Clarity of intent: Descriptive names and comprehensive Javadoc explain responsibilities well; the compound bridge-method condition is less immediately understandable. Code length: Implementation is reasonably concise for reflection and proxy handling, although documentation and the long 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 sequential lookup logic support natural reading, with some interruption from complex conditions and exception-driven interface searching.

Run 3

Code Structure: Well-organized utility class with focused methods and a clearly separated callback interface. Nesting: Mostly manageable, though the loop, lambda, and nested conditionals in metadata selection require extra attention; nested try/catch blocks also add complexity. Clarity of intent: Descriptive names and thorough Javadoc explain the API well, but the bridge-method comparison logic is subtle and lacks an explanatory comment. Code length: Implementation is reasonably concise and reuses the metadata-selection method effectively; documentation is lengthy but useful. Action granularity: Generally one action per statement, with some compact expressions combining filtering, conversion, and result extraction. Reading flow: Consistent formatting, logical sequencing, and early returns support natural reading, although the compound bridge-method condition and exception-driven interface search interrupt the flow.