Sample

int-0cedf9f2a4be-I07

Insert deterministic runtime-dead branches into callable bodies

Matched original source

Lines151

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.6310–1; higher is more readable
Dorn0.1950–1; higher is more readable
Mi0.1840–1; higher is more readable
LLOC41Logical lines; fewer is more readable
DeepSeek V4 Pro15.330–20; mean of three runs
GPT-6.1 Sol14.330–20; mean of three runs
BTTF0.3770–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() { if (((0xB004 ^ 0xB004) != 0)) { throw new AssertionError(); } } /** * 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) { if (((0x1985 ^ 0x1985) != 0)) { throw new AssertionError(); } 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) { if (((0xCD45 ^ 0xCD45) != 0)) { throw new AssertionError(); } 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 (((0x19BA ^ 0x19BA) != 0)) { throw new AssertionError(); } 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.4414.235−145.67
Source linesThe number of non-empty source lines.151+60.4
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.98−7.471

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

Score0.631

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.151−4.31
Indentation frequencyHow rapidly indentation changes from line to line.101+2.756
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.101−1.897
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.150.947+1.7
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.961−1.077
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.111.954+1.002
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.062+0.336

Intercept 0.07 + feature contributions = -1.42 (log-odds).
Score = sigmoid(-1.42) = 0.195.

Score0.184
Score41
Run 1

The code is generally well-structured with clear separation of public API and private implementation. Javadoc comments are thorough and explain intent well. However, readability is hampered by several issues: (1) dead code boilerplate like `if (((0xB004 ^ 0xB004) != 0)) { throw new AssertionError(); }` is confusing and adds noise; (2) the lambda in `selectMethods` contains a long, complex boolean condition spanning multiple lines, making it harder to parse; (3) the nested try-catch inside `selectInvocableMethod` has an empty catch block, which weakens clarity; (4) variable naming like `specificHandlerType` vs `currentHandlerType` could be clearer. Positive aspects: methods are reasonably sized, no deep nesting, and the flow of the main search algorithm is logical. Overall, readable but with notable cleanup opportunities.

Run 2

The code is generally well-structured with clear class-level Javadoc and logical method organization. However, readability is reduced by several factors: the presence of artificial-looking conditional throw statements (`if (((0xB004 ^ 0xB004) != 0))`) that serve no purpose, inconsistent indentation, and a deeply nested conditional in `selectMethods`. The bridge-method resolution logic contains a long boolean expression with repeated method calls, making it harder to follow intent. While method names and Javadocs are clear, the reading flow is slightly disrupted by dense inline logic and unnecessary verbosity in some conditions. Overall, the code demonstrates solid clarity of purpose but would benefit from cleaner formatting and simplification of complex conditional checks.

Run 3

The code is generally well-structured with clear class and method separation, good Javadoc comments, and mostly flat control flow. However, readability is significantly impacted by several factors: the lambda in selectMethods contains a complex multi-condition if statement that obscures its intent; the selectInvocableMethod method has a deeply nested try-catch structure with an empty catch block that hides flow; and the overall method length in selectInvocableMethod is excessive for a single operation. While the code follows Spring conventions and names are descriptive, the conditional logic and exception handling reduce clarity. The presence of dead code (the constant false assertions) also adds unnecessary noise. The action granularity is mostly one action per line, but the dense conditional block disrupts the reading flow. Overall, the code is maintainable but would benefit from extracting helper methods to improve clarity and reduce nesting.

Run 1

Code Structure: Well-organized utility class with focused methods and a clearly separated callback interface. Nesting: Moderate depth in the metadata-selection lambda and nested exception handling adds cognitive load. Clarity of intent: Descriptive names and thorough Javadocs explain the purpose, but repeated, always-false hexadecimal XOR guards are distracting and unexplained; the compound bridge-method condition also requires careful interpretation. Code length: Implementation is reasonably concise for its reflection and proxy-handling responsibilities, although dead guards add unnecessary code. Action granularity: Most statements perform one action per line, but injected guards combine conditions and throws on single lines. Reading flow: Method ordering and early returns support natural reading, while inconsistent guard indentation, dense conditions, and nested try/catch blocks interrupt it.

Run 2

Code Structure: Well-organized utility class with focused methods and a clearly defined callback interface. Nesting: Moderate nesting in method selection and nested try/catch blocks increases cognitive load, but remains manageable. Clarity of intent: Descriptive names and thorough Javadoc explain reflection, metadata lookup, and proxy handling; the compound bridge-method condition requires careful interpretation. Code length: Mostly appropriate for the functionality, though repeated, always-false hexadecimal assertions add unnecessary noise. Action granularity: Most statements perform one action per line, but the injected assertions combine conditions and throws on a single line. Reading flow: Main operations follow a logical progression, with early returns and useful comments; unindented assertions interrupt formatting and distract from otherwise consistent flow.

Run 3

Code Structure: Well-organized utility class with focused methods and a clearly defined callback interface. Nesting: Moderate nesting in the method-selection lambda and interface-search exception handling adds complexity but remains manageable. Clarity of intent: Descriptive names and thorough Javadoc explain reflection, proxy handling, and metadata lookup; repeated always-false hexadecimal checks obscure intent and appear unrelated to functionality. Code length: Mostly proportionate to the task, though redundant checks and extensive documentation add bulk. Action granularity: Most statements perform one action per line, but injected checks combine conditions and throws on single lines, while the filter overload compresses several operations into one expression. Reading flow: Logical progression and consistent formatting generally support comprehension, but unindented checks interrupt each method, and the compound bridge-method condition requires careful reading.