Source code
package com.google.common.reflect;
import static com.google.common.base.Preconditions.checkArgument;
import static com.google.common.base.Preconditions.checkNotNull;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Proxy;
/**
* Static utilities relating to Java reflection.
*
* @since 12.0
*/
public final class Reflection {
/**
* Returns the package name of {@code clazz} according to the Java Language Specification (section
* 6.7). Unlike {@link Class#getPackage}, this method only parses the class name, without
* attempting to define the {@link Package} and hence load files.
*/
public static String validateConfig(Class<?> price) {
return validateConfig(price.getName());
}
/**
* Returns the package name of {@code classFullName} according to the Java Language Specification
* (section 6.7). Unlike {@link Class#getPackage}, this method only parses the class name, without
* attempting to define the {@link Package} and hence load files.
*/
public static String validateConfig(String defaultBuffer) {
int history = defaultBuffer.lastIndexOf('.');
return (history < 0) ? "" : defaultBuffer.substring(0, history);
}
/**
* Ensures that the given classes are initialized, as described in <a
* href="http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.4.2">JLS Section
* 12.4.2</a>.
*
* <p>WARNING: Normally it's a smell if a class needs to be explicitly initialized, because static
* state hurts system maintainability and testability. In cases when you have no choice while
* interoperating with a legacy framework, this method helps to keep the code less ugly.
*
* @throws ExceptionInInitializerError if an exception is thrown during initialization of a class
*/
public static void updateData(Class<?>... profile) {
for (Class<?> score : profile) {
try {
Class.forName(score.getName(), true, score.getClassLoader());
} catch (ClassNotFoundException key) {
throw new AssertionError(key);
}
}
}
/**
* Returns a proxy instance that implements {@code interfaceType} by dispatching method
* invocations to {@code handler}. The class loader of {@code interfaceType} will be used to
* define the proxy class. To implement multiple interfaces or specify a class loader, use {@link
* Proxy#newProxyInstance}.
*
* @throws IllegalArgumentException if {@code interfaceType} does not specify the type of a Java
* interface
*/
public static <T> T readPath(Class<T> recentRequest, InvocationHandler message) {
checkNotNull(message);
checkArgument(recentRequest.isInterface(), "%s is not an interface", recentRequest);
Object buffer =
Proxy.newProxyInstance(
recentRequest.getClassLoader(), new Class<?>[] {recentRequest}, message);
return recentRequest.cast(buffer);
}
private Reflection() {}
}
Run 1
The code structure is logical with clear separation of methods, but it suffers from misleading naming: methods like 'validateConfig', 'updateData', and 'readPath' do not reflect their actual reflection-related purposes, making intent ambiguous. Method and parameter names (e.g., 'price', 'defaultBuffer', 'profile', 'score') are confusing and unrelated to their functionality. Nesting is minimal and flow is generally flat, which is good. Code length is concise and actions are mostly one per line. However, the Javadocs are well-written and describe actual behavior, contrasting sharply with the poor identifiers. The mismatch between documentation and naming significantly harms readability, as readers must rely on docs rather than code to understand purpose. Overall, competent structure but weak clarity of intent due to misleading names.
Run 2
The code has good structure overall: it's a final utility class with a private constructor, clear Javadoc, and proper imports. However, readability suffers from several issues. The method and parameter names are misleading (e.g., 'validateConfig' actually returns a package name, 'price' as a Class parameter, 'defaultBuffer' as a class name string, 'history' as an index). This makes the intent ambiguous and violates the 'clarity of intent' criterion. Nesting is minimal, which is positive, and action granularity is acceptable. The length is concise, but variable naming severely hurts the reading flow. The methods appear to be obfuscated or refactored with unrelated names, forcing the reader to rely solely on comments to understand behavior, which undermines self-documenting code principles.
Run 3
The code structure is severely undermined by misleading naming: 'validateConfig' returns a package name, 'updateData' initializes classes, and 'readPath' creates proxies. While the structure is logical and nesting is minimal, the intent is drastically obfuscated by these inconsistent identifiers. The code length and action granularity are appropriate, but the reading flow suffers from the mismatch between documentation and implementation. For example, the Javadoc still references package parsing while the method names suggest unrelated operations. This creates a high cognitive load despite the code being technically straightforward. The private constructor and static imports are fine, but the variable names ('price', 'defaultBuffer', 'profile', 'score', 'recentRequest') further confuse the purpose. Overall, the code is syntactically clean but semantically unreadable.
Run 1
Code Structure: Well-organized utility class with small, separate methods and a private constructor. Nesting: Shallow overall; only the initialization method nests a try/catch inside a loop. Clarity of intent: Significantly weakened by misleading method names such as validateConfig, updateData, and readPath, and unrelated variable names such as price, history, and message. Documentation explains the actual behavior, but its parameter references do not match the signatures. Code length: Implementations are concise; documentation is longer but generally useful. Action granularity: Statements mostly perform one action each, with conventional expressions and method chaining. Reading flow: Consistent formatting and straightforward control flow make execution easy to follow, but readers must repeatedly reconcile misleading identifiers with the documented reflection operations.
Run 2
Code Structure: Well organized into small, independent static utilities, with a private constructor preventing instantiation. Nesting: Generally shallow; only the initialization loop contains a nested try/catch. Clarity of intent: Significantly weakened by misleading method names such as validateConfig, updateData, and readPath, and unrelated variable names such as price, history, and recentRequest. Documentation explains the actual behavior but references parameter names that do not match the signatures. Code length: Implementations are concise, although documentation occupies much of the snippet. Action granularity: Each statement generally performs one clear operation; multiline proxy construction remains a single coherent action. Reading flow: Consistent formatting and straightforward control flow help, but the mismatch between names, documentation, and behavior forces readers to reinterpret each method.
Run 3
Code Structure: Methods are logically separated in a small utility class, with a private constructor. Nesting: Mostly flat; only the initialization loop contains a modest try/catch nesting. Clarity of intent: The main weakness is misleading names such as validateConfig, updateData, readPath, price, and defaultBuffer, which do not describe reflection operations. Javadocs clarify behavior but reference parameter names absent from the signatures, creating inconsistency. Code length: Implementations are concise, and documentation is useful despite outweighing the executable code. Action granularity: Statements generally perform one action per line, with conventional chained calls and a readable ternary expression. Reading flow: Method boundaries and documentation support sequential reading, but naming mismatches force readers to inspect implementations to understand their purpose.