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 getPackageName(Class<?> clazz) {
return getPackageName(clazz.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 getPackageName(String classFullName) {
int lastDot = classFullName.lastIndexOf('.');
return (lastDot < 0) ? "" : classFullName.substring(0, lastDot);
}
/**
* 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 initialize(Class<?>... classes) {
for (Class<?> clazz : classes) {
try {
Class.forName(clazz.getName(), true, clazz.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 newProxy(Class<T> interfaceType, InvocationHandler handler) {
{
int startingPosition = 2;
int endingPosition = 9;
int travelDistance = endingPosition - startingPosition;
if (travelDistance < 0) {
travelDistance = -travelDistance;
}
}
checkNotNull(handler);
checkArgument(interfaceType.isInterface(), "%s is not an interface", interfaceType);
Object object =
Proxy.newProxyInstance(
interfaceType.getClassLoader(), new Class<?>[] {interfaceType}, handler);
return interfaceType.cast(object);
}
private Reflection() {}
}
Run 1
The code is generally well-structured and readable, with clear method names and Javadoc. However, it contains an unexplained, dead code block inside newProxy() — an unrelated local computation (startingPosition, endingPosition, travelDistance) that serves no purpose and disrupts reading flow. This block is neither commented nor related to the method's intent, making the code confusing. Otherwise, nesting is minimal, actions are mostly one per line, and the utility class follows standard conventions.
Run 2
The code is generally well-structured and documented, with clear intent and good use of helper methods. However, there is a significant readability issue: the `newProxy` method contains an extraneous block of code that calculates `travelDistance` and serves no purpose related to the method's functionality. This dead code introduces confusion and disrupts the reading flow. Additionally, the nested `try-catch` inside the `initialize` method is slightly more complex than necessary but remains acceptable. Overall, the code is mostly readable, but the unrelated code block in `newProxy` lowers its score substantially, as it violates clarity of intent and action granularity.
Run 3
The code is generally well-structured with clear Javadoc and meaningful method names, but there is a significant readability problem: a stray block of unrelated code (startingPosition, endingPosition, travelDistance) appears inside the newProxy method. This block has no connection to the method's purpose, disrupts the reading flow, and violates the 'one action per line' and 'clarity of intent' criteria. Nesting is mostly flat and acceptable, with a simple try-catch in initialize(). The getPackageName methods are concise and clear. The newProxy method, aside from the stray block, is readable and follows logical steps. Overall, the code would be much more readable without the unrelated block, which lowers the score substantially.
Run 1
Code Structure: Utility methods are logically organized, but newProxy contains an unrelated distance-calculation block that disrupts cohesion. Nesting: Generally shallow; initialize uses a reasonable loop with try/catch, while the extraneous block adds unnecessary nesting. Clarity of intent: Descriptive names and Javadoc clearly explain the reflection utilities, but the unused travelDistance calculation has no apparent purpose. Code length: Most methods are concise; the unrelated block adds unnecessary lines. Action granularity: Statements generally perform one action per line, and the multiline proxy creation remains readable. Reading flow: Method ordering and delegation are natural, but inconsistent indentation and the unexpected arithmetic block interrupt the flow. Overall, the reflection logic is readable, with a significant localized distraction.
Run 2
Code Structure: Small, logically separated utility methods are undermined by an unrelated distance-calculation block inside newProxy. Nesting: Mostly shallow; initialize uses reasonable loop/try-catch nesting, while the extraneous block adds unnecessary nesting. Clarity of intent: Descriptive method names and thorough Javadocs clarify reflection operations, but the unused distance calculation has no apparent purpose. Code length: Core implementations are concise; the irrelevant block unnecessarily increases length. Action granularity: Statements generally perform one action per line, and the multiline proxy invocation remains understandable. Reading flow: Method ordering and documentation support natural reading, but the poorly indented injected block abruptly interrupts newProxy and distracts from its validation and proxy creation.
Run 3
Code Structure: Most utilities are logically separated into small methods, but the unrelated travel-distance block disrupts newProxy. Nesting: Generally shallow; initialize has reasonable loop/try-catch nesting, while the extra block and conditional in newProxy add unnecessary depth. Clarity of intent: Descriptive method names and detailed Javadocs explain reflection operations well, but the unused distance calculation has no apparent purpose. Code length: Core implementations are concise; the unrelated block adds avoidable length. Action granularity: Statements generally perform one action per line, and the multiline proxy construction remains readable. Reading flow: Method grouping and validation-before-construction provide a natural flow, interrupted by the poorly indented, irrelevant block.