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) {
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
This code is severely unreadable. The package and import statements are compressed onto a single line, violating standard formatting. Method declarations, Javadoc comments, and method bodies are frequently placed on the same line, destroying visual separation. Opening braces are placed at the end of lines instead of on their own lines, and closing braces are inconsistently placed, even inline with other code. The getPackageName method crams multiple statements onto one line, and the initialize method has poor indentation. While the logic itself is simple, the physical layout makes it extremely difficult to scan. The code lacks any whitespace or structural cues to guide the reader, forcing them to mentally parse compressed lines. Although the variable names are clear and the Javadoc content is informative, the formatting completely undermines readability.
Run 2
The code is extremely difficult to read due to severe formatting problems. Multiple statements are crammed onto single lines, and method declarations share lines with Javadoc comments. The indentation is inconsistent and sometimes missing entirely, destroying the visual hierarchy that would normally convey structure. While the underlying logic is simple, the formatting makes it nearly impossible to follow. The code structure is technically present but obscured; nesting depth is low but hard to perceive. Clarity of intent is buried under poor layout, and reading flow is severely disrupted. This appears to be valid code that has lost all formatting, perhaps due to a tool or copy-paste issue. Reformatting would dramatically improve readability.
Run 3
The code has severe readability issues primarily due to formatting. Multiple declarations and statements are compressed onto single lines, including entire method signatures and bodies (e.g., 'public static String getPackageName...'). This violates action granularity and disrupts natural reading flow. While the logic itself is simple and the class structure is logically organized, the physical layout makes it appear tangled and ambiguous. The nesting depth is acceptable, and intent is mostly clear from Javadoc, but the compressed formatting obscures clarity. The code is concise to a fault, sacrificing readability for brevity. Proper line breaks and indentation would dramatically improve the score.
Run 1
Code Structure: Methods are logically grouped in a focused reflection utility class, but inconsistent formatting obscures their boundaries. Nesting: Mostly shallow; initialize has a manageable loop with try/catch. Clarity of intent: Descriptive method names, straightforward operations, and detailed Javadoc clearly communicate purpose. Code length: Implementations are concise, and documentation is relevant, though visually dominant. Action granularity: Several lines combine declarations, statements, or structural elements, making individual actions harder to scan. Reading flow: The logical progression is natural, but package/import combinations, comments attached to braces, and compressed method bodies repeatedly interrupt visual flow. Consistent line breaks and indentation would substantially improve readability.
Run 2
Code Structure: Related reflection utilities are logically grouped into small, independent methods, but compressed formatting obscures boundaries. Nesting: Shallow overall; only initialize adds a loop and try/catch. Clarity of intent: Descriptive method names, straightforward operations, and detailed Javadocs clearly explain purpose. Code length: Implementation is concise without unnecessary logic, though documentation occupies much of the snippet. Action granularity: Several lines combine declarations, statements, or structural elements, making individual actions harder to distinguish. Reading flow: Inconsistent line breaks, comments attached to declarations, and closing braces sharing lines interrupt otherwise natural top-to-bottom reading. Conventional formatting would substantially improve readability without changing the design.
Run 3
Code Structure: Logically organized into small, independent reflection utilities, though compressed formatting obscures boundaries. Nesting: Shallow overall; only initialization introduces a loop with try/catch. Clarity of intent: Descriptive method names, straightforward operations, and detailed Javadoc make purpose clear. Code length: Implementations are concise without unnecessary logic; documentation adds useful context. Action granularity: Several lines combine declarations, statements, imports, or braces, undermining the one-action-per-line principle. Reading flow: Inconsistent line breaks and comments attached to declarations interrupt scanning, especially in getPackageName and initialize. Conventional formatting would substantially improve readability without changing the design.