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 get(Class<?> cla) {
return get(cla.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 get(String class2) {
int last = class2.lastIndexOf('.');
return (last < 0) ? "" : class2.substring(0, last);
}
/**
* 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 ini(Class<?>... cla2) {
for (Class<?> cla3 : cla2) {
try {
Class.forName(cla3.getName(), true, cla3.getClassLoader());
} catch (ClassNotFoundException e) {
throw new AssertionError(e);
}
}
}
/**
* 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 new2(Class<T> interface2, InvocationHandler han) {
checkNotNull(han);
checkArgument(interface2.isInterface(), "%s is not an interface", interface2);
Object obj =
Proxy.newProxyInstance(
interface2.getClassLoader(), new Class<?>[] {interface2}, han);
return interface2.cast(obj);
}
private Reflection() {}
}
Run 1
The code structure is logical, with clear separation of concerns and good documentation comments. Nesting is minimal, and the reading flow is natural. However, clarity of intent suffers due to non-descriptive parameter names like 'cla', 'class2', 'cla2', 'cla3', 'interface2', 'han', and method names like 'ini' and 'new2'. Action granularity is generally good but slightly inconsistent, such as combining initialization and iteration in the for-loop header. Code length is concise. The public API is well-documented, but the shortened identifiers make the code less self-explanatory than it could be.
Run 2
The code has a clear overall structure with appropriate separation of methods and Javadoc comments, but the naming convention drastically reduces readability. Method names like 'get', 'ini', and 'new2' are cryptic and fail to convey their actual purpose (getPackageName, initialize, newProxy). Parameter names like 'cla', 'class2', 'cla2', 'cla3', and 'han' are heavily abbreviated or numbered, creating confusion about their roles. The logic itself is straightforward and well-organized, with reasonable nesting and line lengths. The Javadoc is thorough and helpful. However, the code appears to have been deliberately obfuscated by stripping meaningful identifiers, which severely impacts clarity of intent. The reading flow suffers because readers must constantly map abbreviated names to their actual function. While the structural elements are sound, the identifier quality—a crucial aspect of readability—is poor, bringing the score down significantly.
Run 3
The code is generally well-structured and documented, with clear intent and flat nesting. However, the parameter and method names are highly obfuscated (e.g., 'cla', 'class2', 'ini', 'new2', 'han') which significantly harms clarity and readability. The class and method documentation is detailed, but the shortened names contradict the otherwise natural reading flow. The logic is concise and each line typically performs a single action, but the poor naming forces the reader to rely on comments to understand what the code does. Improving the names to match the documentation (e.g., 'clazz', 'className', 'initialize', 'newProxy') would greatly increase the score.
Run 1
1. Code Structure: Well-organized utility class with small, independent methods and a private constructor. 2. Nesting: Mostly flat; the initialization method has only a loop containing a try/catch. 3. Clarity of intent: Detailed documentation explains each operation, but vague names such as get, ini, new2, cla2, and han obscure intent. Documentation also references parameter names that differ from the actual signatures. 4. Code length: Implementations are concise without unnecessary logic; documentation is lengthy but useful. 5. Action granularity: Statements generally perform one action per line, with clear validation and return steps. 6. Reading flow: Consistent formatting and straightforward execution support natural reading, although abbreviated identifiers and minimal spacing around imports reduce polish.
Run 2
Code Structure: Well-organized utility class with small, independent methods and a private constructor. Nesting: Mostly flat; the initialization loop contains only a necessary try/catch. Clarity of intent: Detailed documentation explains behavior, but vague names such as get, ini, new2, cla2, and han obscure intent. Documentation also references parameter names that no longer match the signatures. Code length: Implementations are concise, and the longer comments provide useful context. Action granularity: Statements generally perform one action per line; multiline proxy construction remains understandable. Reading flow: Methods follow a natural sequence and use consistent formatting, though compressed import spacing and cryptic identifiers interrupt otherwise smooth reading.
Run 3
Code Structure: Small, logically separated utility methods and a private constructor provide clear organization. Nesting: Mostly flat; the initialization method has modest, justified loop and try/catch nesting. Clarity of intent: Detailed documentation explains behavior, but vague names such as get, ini, new2, cla2, and han obscure intent. Documentation also references parameter names that no longer match the signatures. Code length: Implementations are concise without unnecessary logic; documentation is longer but useful. Action granularity: Statements generally perform one action per line, and multiline proxy construction remains easy to follow. Reading flow: Method-level flow is natural and predictable, although inconsistent naming and tightly packed package/import declarations reduce polish.