Sample

int-9600db7f4f35-I13

Lower every eligible classic and enhanced for loop to a while loop

Matched original source

Lines152

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.6280–1; higher is more readable
Dorn0.190–1; higher is more readable
Mi0.170–1; higher is more readable
LLOC38Logical lines; fewer is more readable
DeepSeek V4 Pro13.670–20; mean of three runs
GPT-6.1 Sol150–20; mean of three runs
BTTF0.4660–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)); { java.util.Iterator<?> loopIterator = (handlerTypes).iterator(); while (loopIterator.hasNext()) { Class<?> currentHandlerType = (Class<?>) loopIterator.next(); 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(); { Class<?>[] loopArray = targetType.getInterfaces(); int loopIndex = 0; while (loopIndex < loopArray.length) { Class<?> ifc = loopArray[loopIndex++]; 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.4248.542−140.202
Source linesThe number of non-empty source lines.152+60.8
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.911−7.366

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

Score0.628

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.153−4.381
Indentation frequencyHow rapidly indentation changes from line to line.102+2.791
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.102−1.92
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.151.832+1.712
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.967−1.077
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.111.98+1.002
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.06+0.355

Intercept 0.07 + feature contributions = -1.447 (log-odds).
Score = sigmoid(-1.447) = 0.19.

Score0.17
Score38
Run 1

The code demonstrates strong readability overall with clear class structure, well-documented methods, and logical organization. Javadoc comments thoroughly explain each method's purpose. The main selectMethods method uses a clean callback pattern and maintains flat structure despite complex logic. However, there are minor readability issues: the explicit Iterator loop could be replaced with a for-each loop for cleaner intent, and the if condition checking bridged methods has multiple OR conditions that could benefit from extraction to a helper method. The selectInvocableMethod uses a while loop over interfaces instead of a simpler for-each construct, suggesting possible auto-generated code. Variable names are descriptive but some like 'specificHandlerType' and 'currentHandlerType' could be clearer. The nested lambda in selectMethods adds slight complexity but is well-indented. Overall the code follows Spring framework conventions and remains maintainable despite handling complex reflection scenarios.

Run 2

The code has clear Javadoc and a logical purpose, but readability suffers due to inconsistent structure and verbose blocks. The use of an unusual `{ ... }` block with an explicit iterator in `selectMethods` disrupts natural reading flow and adds unnecessary complexity compared to a simple enhanced for-loop. Similarly, the arrays-based loop in `selectInvocableMethod` is harder to follow than a for-each loop. Deep conditional nesting inside the lambda—especially the multi-condition bridge method check—reduces clarity. While each action is mostly on its own line and intent is generally clear, the code is unnecessarily long in places and could be flattened and simplified. The class-level documentation is helpful, but the implementation would benefit from cleaner iteration and reduced nesting.

Run 3

The code is moderately readable but has several issues. The overall structure is logical with clear class and method separation, but there are problems with nesting, particularly in the `selectMethods` method where a lambda contains deep conditional logic. The manually unrolled iterator loops (while loops instead of for-each) reduce readability and introduce unnecessary complexity. The bridge method resolution logic is convoluted with multiple OR conditions that are difficult to parse. Intent is mostly clear from documentation but the implementation obscures it. Code length is reasonable but the loop unrolling makes it feel longer than necessary. Action granularity is inconsistent, with some complex operations packed into single lambdas. Reading flow is disrupted by the artificially verbose iterator handling.

Run 1

Code Structure: Well-organized utility class with focused methods and a clearly defined callback interface. Nesting: Moderate-to-deep nesting in method selection and interface lookup, amplified by unnecessary scope blocks and explicit while loops. Clarity of intent: Descriptive names, comprehensive Javadocs, and useful comments explain the purpose, though bridge-method handling and the compound condition require careful interpretation. Code length: Reasonable for the functionality, but verbose iterator/index machinery could be replaced with enhanced for loops. Action granularity: Most lines perform one action; the indexed access with post-increment combines retrieval and advancement. Reading flow: Methods follow a logical progression, and early returns help, but inconsistent indentation, redundant parentheses, casts, and nested exception handling interrupt otherwise natural flow.

Run 2

Code Structure: Well-organized utility class with focused methods, clear overloads, and a small callback interface. Nesting: Moderate to deep in the main selection method, where explicit iteration wraps a lambda and nested conditionals; interface lookup also nests exception handling. Clarity of intent: Descriptive names and thorough Javadocs explain the API, although the compound bridge-method condition requires careful interpretation. Code length: Mostly justified by reflection and proxy handling, but manual iterator/index loops and extra scope blocks add unnecessary verbosity compared with enhanced for-loops. Action granularity: Generally one operation per line; the array access with post-increment combines traversal actions, and the filtering overload compresses several operations into one expression. Reading flow: Public methods follow a logical progression, with useful early returns and comments. However, inconsistent indentation in expanded loops, redundant parentheses, and lengthy conditions interrupt an otherwise natural flow.

Run 3

Code Structure: Well-organized utility class with focused methods and a clearly separated callback interface. Nesting: Mostly manageable, but redundant blocks, explicit while loops, nested conditionals, and a lambda make metadata selection harder to follow. Clarity of intent: Descriptive names and thorough Javadocs explain the purpose; the compound bridge-method condition requires careful interpretation. Code length: Reasonable overall, though manual iteration, casts, and temporary loop variables add unnecessary verbosity compared with enhanced for loops. Action granularity: Most lines perform one action, but the array access with post-increment combines retrieval and index advancement. Reading flow: Methods generally progress naturally from setup through lookup to return or failure; inconsistent indentation in loop blocks and the long Boolean condition interrupt scanning.