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() {
{int lI0O_5af96ce7=0x9D8D;lI0O_5af96ce7=((lI0O_5af96ce7^0x9D8D)|0)&-1;if(((lI0O_5af96ce7&1)==1)){lI0O_5af96ce7^=lI0O_5af96ce7;}}
}
}
Run 1
The code is well-structured with clear package organization, proper imports, and a final utility class with a private constructor. It has minimal nesting, concise methods, and strong documentation that clarifies intent. Each method performs a single, focused action, and the reading flow is natural. The only issue is the obfuscated code in the private constructor, which is completely unreadable and unnecessary. Otherwise, the code would score a 20.
Run 2
The code is generally well-structured with clear method separation and good Javadoc documentation. However, readability is significantly damaged by the obfuscated code injected into the private constructor, which serves no legitimate purpose and makes the intent completely unclear. The public methods are mostly readable, with reasonable naming and concise logic, although the method to get a package name uses a ternary expression that could be slightly clearer with a guard clause. The `initialize` method has a try-catch that adds necessary complexity but is still readable. The `newProxy` method is straightforward but could benefit from breaking the `Proxy.newProxyInstance` call into smaller steps. Overall, the deliberate obfuscation severely lowers the score.
Run 3
The code is generally well-structured with clear method separation, logical organization, and good documentation. Nesting is minimal, and most actions are granular with clear intent. However, readability is significantly reduced by the obfuscated code inside the private constructor, which is meaningless, confusing, and likely malicious or accidental. This single issue disrupts reading flow and forces developers to question the codebase's integrity. Otherwise, the class is concise and maintains a natural progression of utility methods.
Run 1
Code Structure: The utility methods are logically organized, but the constructor contains an unrelated, obfuscated block. Nesting: Most methods are flat; initialize has reasonable loop/try-catch nesting, while the constructor adds unnecessary scopes and a conditional. Clarity of intent: Descriptive method names and useful documentation explain the reflection utilities well, but the constructor's cryptic variable and bitwise operations obscure its purpose. Code length: The methods are concise, though the constructor introduces unnecessary computation. Action granularity: Most statements occupy separate lines; the constructor compresses declarations, assignments, and control flow onto one line. Reading flow: Consistent formatting and documentation support natural reading until the densely packed, poorly indented constructor abruptly disrupts it.
Run 2
Code Structure: Public utilities are logically separated into small methods, but the private constructor contains an unrelated obfuscated block. Nesting: Most methods are flat; the initialization loop has modest try/catch nesting, and the constructor adds unnecessary block and conditional nesting. Clarity of intent: Descriptive method names and thorough Javadoc make the utilities clear, whereas the constructor's cryptic variable and bitwise operations obscure its purpose. Code length: Utility implementations are concise, but the constructor adds unnecessary computation. Action granularity: Most statements occupy separate lines; the constructor compresses several assignments and a conditional onto one line. Reading flow: Consistent formatting and documentation support natural reading until the densely packed, poorly formatted constructor abruptly disrupts it.
Run 3
Code Structure: Public utilities are logically organized into focused methods, but the constructor contains unrelated obfuscated code. Nesting: Most methods are flat; the initialization loop has reasonable try/catch nesting, while the constructor adds unnecessary block and conditional nesting. Clarity of intent: Descriptive method names and useful documentation explain the reflection operations clearly; the constructor's cryptic identifier and bitwise operations obscure its purpose. Code length: Utility implementations are concise, but the constructor adds needless complexity. Action granularity: Most statements perform one clear action per line; the constructor compresses declarations, assignments, and a conditional onto one line. Reading flow: Consistent formatting and documentation make the main methods easy to follow, but the abruptly unformatted constructor significantly disrupts the otherwise natural flow.