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 a(Class<?> a) {
return a(a.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 a(String b) {
int c = b.lastIndexOf('.');
return (c < 0) ? "" : b.substring(0, c);
}
/**
* 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 b(Class<?>... d) {
for (Class<?> f : d) {
try {
Class.forName(f.getName(), true, f.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 c(Class<T> g, InvocationHandler h) {
checkNotNull(h);
checkArgument(g.isInterface(), "%s is not an interface", g);
Object i =
Proxy.newProxyInstance(
g.getClassLoader(), new Class<?>[] {g}, h);
return g.cast(i);
}
private Reflection() {}
}
Run 1
The code has clear Javadoc, flat structure, and one action per line, but severely suffers from obfuscated naming. Method names (a, b, c) and parameters (a, b, c, d, f, g, h, i) are meaningless, making intent ambiguous despite good documentation. The structure is logical and nesting is minimal; class initialization and proxy creation are concise. However, the reading flow is disrupted by cryptic identifiers that force constant mental mapping. Code length is appropriate, and action granularity is generally good, but clarity of intent is critically undermined.
Run 2
The code uses meaningless single-letter method names (a, b, c) and parameters (a, b, c, d, f, g, h, i), making the purpose of each method completely unclear without reading the Javadoc. The structure is moderately organized with logical method separation, and nesting is minimal — both positives. However, clarity of intent suffers severely due to obfuscated names. Action granularity is acceptable (one action per line mostly), and reading flow is poor because the names don't aid comprehension. The Javadoc is comprehensive and would normally improve readability, but it's undermined by the cryptic identifiers. Renaming methods and parameters to descriptive names (e.g., getPackageName, initialize, newProxy) would immediately raise readability significantly.
Run 3
The code structure is logical and the methods are relatively short, but naming is severely obfuscated (a, b, c, d, f, g, h, i), obscuring intent. Variable names like 'a' for class objects and methods like 'a()' and 'b()' make it impossible to infer purpose from names alone without reading Javadoc. Nesting is acceptable—one loop with a try/catch, one conditional—but the forced flatness doesn't improve readability because names are meaningless. Action granularity and reading flow are reasonable, with one main action per line and natural ordering. Javadoc is thorough and provides context, but code identifiers negate its benefit, forcing readers to constantly map generic labels to concepts. Length is concise, not overly long, but brevity here works against clarity by removing descriptive identifiers. The code is maintainable only with documentation, which highlights how poor naming undermines otherwise straightforward reflection utilities.
Run 1
Code Structure: Utilities are logically separated into short methods within a non-instantiable class. Nesting: Mostly flat, with only a loop containing try/catch adding modest depth. Clarity of intent: Detailed documentation explains each utility, but single-letter method and variable names obscure meaning; documentation parameter names also differ from actual identifiers. Code length: Implementations are concise, although documentation dominates the file. Action granularity: Statements generally perform one action each, with readable validation and return steps. Reading flow: Methods follow a natural sequence, but overloaded methods named 'a' and awkward wrapping of the proxy creation statement interrupt comprehension. Overall, clean organization and helpful documentation are undermined primarily by non-descriptive naming.
Run 2
Code Structure: Well-organized utility class with small, independent methods and a private constructor. Nesting: Mostly flat; only class initialization introduces a modest loop and try/catch. Clarity of intent: Detailed Javadocs explain behavior, but single-letter method and variable names obscure intent and force reliance on documentation. Some documented parameter names do not match actual parameters. Code length: Implementations are concise; documentation is lengthy but useful. Action granularity: Each statement generally performs one action, with no crowded multi-statement lines. Reading flow: Methods follow a natural sequence, though compressed imports and awkward wrapping of the proxy creation slightly interrupt readability. Overall, strong structure and documentation are weakened primarily by non-descriptive identifiers.
Run 3
Code Structure: Well-organized utility class with small, independent methods and a private constructor. Nesting: Shallow overall; only class initialization introduces a loop containing try/catch. Clarity of intent: Detailed documentation explains each operation, but single-letter method and variable names obscure meaning, and documented parameter names do not match actual names. Code length: Implementations are concise; documentation is extensive but useful. Action granularity: Statements generally perform one action each, with no crowded multi-statement lines. Reading flow: Consistent formatting and straightforward control flow make the code easy to follow, although ambiguous overloaded names and awkward wrapping of proxy creation interrupt comprehension.