Sample

int-a6d83ced569a-I09

Select one of ten low-readability unrelated code templates per class

Matched original source

Lines145

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.7590–1; higher is more readable
Dorn0.1010–1; higher is more readable
Mi0.1710–1; higher is more readable
LLOC38Logical lines; fewer is more readable
DeepSeek V4 Pro120–20; mean of three runs
GPT-6.1 Sol140–20; mean of three runs
BTTF0.1750–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) { {int lI0O_fd22ed78=0,lI0O_7c2d73a9=0;while(lI0O_7c2d73a9<2){lI0O_fd22ed78^=(lI0O_7c2d73a9<<1)^0xE;lI0O_7c2d73a9++;}lI0O_fd22ed78^=lI0O_fd22ed78;} 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.4068.314−134.254
Source linesThe number of non-empty source lines.145+58
Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value.5−7.499

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

Score0.759

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.145−4.098
Indentation frequencyHow rapidly indentation changes from line to line.95+2.549
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.966−2.475
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.95−1.759
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.144.877+1.615
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.058+0.375

Intercept 0.07 + feature contributions = -2.188 (log-odds).
Score = sigmoid(-2.188) = 0.101.

Score0.171
Score38
Run 1

The code is generally well-structured with clear class and method separation, good use of Javadoc, and mostly flat nesting. However, there is a suspicious line of obfuscated code `{int lI0O_fd22ed78=0,lI0O_7c2d73a9=0;while...}` inside selectMethods that serves no apparent purpose and severely harms readability. The bridge method resolution condition is complex and could be extracted for clarity. The selectInvocableMethod has nested try-catch blocks but remains understandable. Overall the code is maintainable and readable for experienced Java developers, but the obfuscated line is a major red flag.

Run 2

The code is generally well-structured with clear class-level documentation and logical method separation. However, there is a significant readability issue: an obfuscated, non-functional line with meaningless variable names is inserted at the start of the selectMethods method, breaking flow and intent. The main method's logic is reasonably flat but contains a complex multi-condition bridge method check that could be extracted for clarity. The selectInvocableMethod uses nested try-catch blocks, which adds depth, though it remains understandable. Javadocs are excellent and improve clarity of intent, but the odd inserted code and dense conditional reduce overall readability.

Run 3

The code structure is generally logical, with clear method separation and a clean class-level flow. However, readability is severely hindered by an unexpected obfuscated line (`int lI0O_fd22ed78...`) injected into the `selectMethods` method without purpose or comment. Nesting remains moderate—reflection loops and conditionals are not deeply indented—but the deep conditional chain for bridge method resolution is visually dense and hard to follow. Variables are reasonably named but the overall intent of the bridge method logic is unclear, especially without explanatory comments. Code length is acceptable but could be shortened by extracting methods. Action granularity is poor in the conditional block because several conditions and assignments are packed together. Reading flow is disrupted by the obfuscated line and a long catch handling block that hides control flow. The code is maintainable in principle but fails to consistently prioritize clarity and simplicity, hence a below-average readability score.

Run 1

Code Structure: Well-organized utility class with focused methods and a clearly defined callback interface, but an unrelated obfuscated block disrupts the main method. Nesting: Moderate nesting in method traversal and exception handling increases reading effort without becoming excessive. Clarity of intent: Descriptive names and comprehensive documentation explain the reflection logic; the meaningless variable names and redundant bitwise operations obscure intent locally. Code length: Most implementation code is appropriately concise, but the injected block adds unnecessary code. Action granularity: Most lines express one action, while the injected block compresses declarations, iteration, and mutations onto one line. Reading flow: Consistent formatting and logical progression generally support natural reading, interrupted by the unformatted block and a complex bridge-method condition.

Run 2

Code Structure: Well-organized utility class with focused methods and a clearly separated callback interface, but an unrelated no-op block disrupts cohesion. Nesting: Moderate nesting in the method-selection lambda and interface-search exception handling adds complexity without becoming excessive. Clarity of intent: Descriptive names and thorough Javadocs explain the main behavior; opaque variables and meaningless arithmetic in the injected block obscure intent, while the bridge-method condition requires careful reading. Code length: Mostly justified by reflection and proxy handling, though the no-op block is unnecessary. Action granularity: Most statements perform one action per line, but the injected block compresses declarations, iteration, and arithmetic onto one line. Reading flow: Generally natural progression from setup through selection to results, with consistent formatting elsewhere; the unindented block and lengthy conditional interrupt that flow.

Run 3

Code Structure: Methods are logically separated, with a focused callback interface, but an unrelated arithmetic block disrupts the organization. Nesting: Mostly moderate, though the loop/lambda/conditional combination and nested exception handling require extra attention. Clarity of intent: Descriptive names and thorough Javadoc explain method selection and proxy handling; the opaque variable names and pointless arithmetic obscure intent locally, while the bridge-method condition is complex. Code length: Generally appropriate for the functionality, but the arithmetic block adds unnecessary code. Action granularity: Most statements perform one action per line; the injected block compresses declarations, a loop, and several operations onto one line. Reading flow: The main algorithms progress naturally, supported by comments and early returns, but the unformatted block and long compound condition interrupt otherwise consistent flow.