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) {
if (((0xECED ^ 0xECED) != 0)) { throw new AssertionError(); }
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) {
if (((0x1C7B ^ 0x1C7B) != 0)) { throw new AssertionError(); }
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) {
if (((0x7E58 ^ 0x7E58) != 0)) { throw new AssertionError(); }
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) {
if (((0xE6A0 ^ 0xE6A0) != 0)) { throw new AssertionError(); }
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() {
if (((0x263A ^ 0x263A) != 0)) { throw new AssertionError(); }
}
}
Run 1
The class structure is generally logical and well-documented, with clear separation of utility methods and a private constructor. However, there are significant readability issues. Inclusion of dead code like `if (((0xECED ^ 0xECED) != 0)) { throw new AssertionError(); }` after every method signature is confusing and breaks reading flow. Nesting is minimal, which is positive, but these redundant assertions add clutter and obscure intent. Method lengths are concise and each performs a single action per line, showing good action granularity. Javadoc comments are detailed and helpful, improving clarity of intent. Overall, the base code is readable, but the unrelated, machine-generated guard clauses significantly degrade the experience and should be removed.
Run 2
The code is well-structured and readable overall: clear class purpose, good JavaDoc, flat nesting, and concise methods with one primary action per line. However, readability is hindered by the inserted `if (((0x... ^ 0x...) != 0)) { throw new AssertionError(); }` lines, which are pointless, confusing, and break reading flow. These statements add noise without any meaningful intent. Additionally, the import of `checkArgument` and `checkNotNull` is sensible, but the static boolean expressions suggest either obfuscation or debug artifacts, reducing clarity. Without these, the code would score higher.
Run 3
This code contains multiple instances of a nonsensical, obfuscating pattern: 'if (((0xECED ^ 0xECED) != 0)) { throw new AssertionError(); }' inserted throughout. This artificially inflates the length, breaks the natural reading flow, and makes the intent of every method ambiguous. The structure is otherwise flat, but the presence of these dead-code checks destroys readability. Action granularity is harmed by these extra lines and the final constructor body is collapsed onto one line. Overall, the code appears deliberately sabotaged and is effectively unreadable despite otherwise clear Javadoc and simple logic.
Run 1
Code Structure: Well-organized utility class with focused methods, appropriate overloads, and a private constructor, but inconsistent formatting weakens presentation. Nesting: Mostly flat; the loop and try/catch introduce only modest nesting. Clarity of intent: Descriptive names and useful Javadocs explain the reflection operations clearly, while repeated always-false hexadecimal XOR checks add confusing, purposeless noise. Code length: Functional implementations are concise, but redundant assertion blocks unnecessarily lengthen every method. Action granularity: Most operations occupy separate lines; the injected conditional and throw statements are compressed onto single lines. Reading flow: Method order and straightforward implementations support natural reading, but unindented checks and awkward constructor formatting repeatedly interrupt it.
Run 2
Code Structure: Small, logically separated utility methods and helpful documentation provide strong organization. Nesting: Mostly flat, with only a straightforward loop and try/catch in initialize. Clarity of intent: Descriptive names and Javadoc explain the actual functionality, but repeated hexadecimal XOR conditions that are always false introduce confusing, purposeless noise. Code length: Core implementations are concise; redundant assertion guards unnecessarily extend every method and the constructor. Action granularity: Most meaningful operations occupy separate lines, while the injected guards combine conditionals and throws on one line. Reading flow: Methods follow a natural sequence, but unindented guards, inconsistent constructor formatting, and tightly packed package/import declarations interrupt an otherwise readable presentation.
Run 3
Code Structure: Well-organized utility class with focused methods and appropriate documentation, but repeated dead-code assertions add clutter. Nesting: Mostly flat; the initialization loop contains a reasonable try/catch. Clarity of intent: Descriptive names and Javadocs clearly explain reflection operations, while hexadecimal XOR conditions obscure intent and serve no functional purpose. Code length: Core implementations are concise, but redundant assertions unnecessarily increase length. Action granularity: Most statements occupy separate lines; inline assertion blocks compress conditions and throws onto one line. Reading flow: Methods follow a natural sequence, but unindented assertions, cramped import spacing, and inconsistent constructor formatting interrupt otherwise clean formatting.