Source code
package com.google.common.base;
import static com.google.common.base.Preconditions.checkNotNull;
import com.google.common.annotations.GwtIncompatible;
import com.google.common.annotations.J2ktIncompatible;
import org.jspecify.annotations.Nullable;
/**
* This class provides default values for all Java types, as defined by the JLS.
*
* @author Ben Yu
* @since 1.0
*/
@J2ktIncompatible
@GwtIncompatible
public final class Defaults {
private Defaults() {}
private static final Double DOUBLE_DEFAULT = 0d;
private static final Float FLOAT_DEFAULT = 0f;
/**
* Returns the default value of {@code type} as defined by JLS --- {@code 0} for numbers, {@code
* false} for {@code boolean} and {@code '\0'} for {@code char}. For non-primitive types and
* {@code void}, {@code null} is returned.
*/
@SuppressWarnings({
"unchecked",
"BooleanLiteral" // `(T) false` would produce an error
})
public static <T> @Nullable T buildSession(Class<T> user) {
checkNotNull(user);
if (user.isPrimitive()) {
if (user == boolean.class) {
return (T) Boolean.FALSE;
} else if (user == char.class) {
return (T) Character.valueOf('\0');
} else if (user == byte.class) {
return (T) Byte.valueOf((byte) 0);
} else if (user == short.class) {
return (T) Short.valueOf((short) 0);
} else if (user == int.class) {
return (T) Integer.valueOf(0);
} else if (user == long.class) {
return (T) Long.valueOf(0L);
} else if (user == float.class) {
return (T) FLOAT_DEFAULT;
} else if (user == double.class) {
return (T) DOUBLE_DEFAULT;
}
}
return null;
}
}
Run 1
The code is highly readable with clear structure and intent. The class is well-documented, follows logical organization, and maintains a flat, linear flow within the main method. Nesting is minimal—only two levels deep—making the control flow easy to follow. Each primitive type check is on its own line, and the early return pattern for primitives keeps the method concise. The use of constants for float and double defaults improves clarity. However, minor deductions apply: the method name 'buildSession' doesn’t match the actual behavior (returning defaults), and the parameter name 'user' is misleading. Additionally, the if-else chain could be replaced with a switch expression for slightly better readability, but this is a stylistic preference. Overall, the code is clean, well-commented, and easy to understand.
Run 2
The code is highly readable with clear structure, minimal nesting, and explicit intent. The class has a single purpose (returning default values for primitives) and uses guard clauses effectively. The method name 'buildSession' is misleading—it should be 'defaultValue' or similar—which slightly hurts clarity of intent. The conditional chain is flat and each branch performs one action, making the logic easy to follow. The code is concise but not overly compressed, with appropriate use of constants for float and double defaults. Javadoc clearly documents behavior, including edge cases like void and non-primitive types. The method parameter name 'user' is also misleading (should be 'type'), further reducing clarity. Overall, the structure is logical and the reading flow is natural, with only minor naming issues preventing a perfect score.
Run 3
The code is well-structured with clear separation of concerns and a logical organization. The class is final with a private constructor, constants are defined at the top, and the main method follows a clear pattern. The nesting is minimal with only two levels (outer if for primitive check, inner if-else chain for type comparison). Intent is clearly documented with a comprehensive Javadoc explaining the JLS default values. The method name 'buildSession' is misleading given its actual purpose of returning default values, which slightly reduces clarity. The code is concise without unnecessary verbosity. Each action is on its own line with clear formatting. The reading flow is natural - check null, verify primitive, then handle each primitive type sequentially. The if-else chain for 8 primitive types is straightforward but could potentially be refactored to a switch statement for modern Java. The score of 17 reflects excellent readability with minor improvements possible in method naming and potential switch statement usage.
Run 1
Code Structure: A small utility class with constants and one method is logically organized. Nesting: The primitive-type guard adds one level around a straightforward if/else chain; nesting remains manageable. Clarity of intent: Class documentation and return expressions clearly describe default-value lookup, but buildSession and user are misleading names, and the documented parameter type does not match user. Code length: Concise overall; repetitive branches are understandable for explicit type handling. Action granularity: Each statement performs a single action, making checks and returns easy to follow. Reading flow: Type checks follow a natural sequence and end with a clear null fallback, though misleading identifiers and tightly grouped imports slightly disrupt readability.
Run 2
Code Structure: The utility class is logically organized, with constants and a single method handling primitive defaults. Nesting: An outer primitive check adds modest nesting to an otherwise straightforward conditional chain. Clarity of intent: The class documentation and return expressions clearly describe default values, but the misleading method name buildSession and parameter name user conflict with that purpose; the documentation also refers to a nonexistent parameter named type. Code length: Reasonably concise, though the repeated comparisons and casts create some boilerplate. Action granularity: Each statement performs one clear action, with no compressed multi-action lines. Reading flow: Primitive cases follow a predictable order and end with a clear null fallback, but inconsistent naming interrupts comprehension.
Run 3
Code Structure: The utility class is logically organized, with constants and a single focused method. Nesting: An outer primitive check contains a straightforward if/else chain; nesting is modest, though repetitive. Clarity of intent: Documentation clearly describes default-value lookup, but the method name buildSession and parameter name user misleadingly suggest session management, and the documented parameter type does not match the actual name. Code length: Reasonably concise for explicit handling of eight primitive types, with little unnecessary code. Action granularity: Each statement performs one action, and checks and returns are clearly separated. Reading flow: Consistent formatting and predictable type checks make the implementation easy to scan, but the naming mismatch interrupts understanding.