Creating and Destroying Objects

Common naming patterns:

• from - Type-conversion method taking single parameter

  Date d = Date.from(instant);

• of - Aggregation method taking multiple parameters

  Set<Rank> faceCards = EnumSet.of(JACK, QUEEN, KING);

• valueOf - More verbose alternative to from/of

  BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE);

• instance/getInstance - Returns instance described by parameters (might be shared)

  StackWalker luke = StackWalker.getInstance(options);

• create/newInstance - Guarantees a new instance each call

  Object newArray = Array.newInstance(classObject, arrayLen);

• getType/newType/type - When factory is in different class

  FileStore fs = Files.getFileStore(path);
  BufferedReader br = Files.newBufferedReader(path);
  List<Complaint> litany = Collections.list(legacyLitany);

Main limitation: Both static factories and constructors don't scale well with many optional parameters.

Three construction patterns compared:

1. Telescoping Constructor Pattern

   • Creates multiple constructors with increasing parameters
   • Problem: Hard to write/read with many parameters; parameter order errors

2. JavaBeans Pattern

   • Use parameterless constructor + setters
   • Problems:
     • Object may be in inconsistent state during construction
     • Precludes immutability
     • Requires manual thread safety

3. Builder Pattern

   • Call constructor/factory with required parameters to get builder
   • Set optional parameters with fluent methods
   • Call build() to get immutable result
   • Benefits: Readable, safe, supports immutability

The Builder pattern combines telescoping constructor safety with JavaBeans readability.

Hierarchical Builder Pattern uses recursive generics to support inheritance in builders:

// Base class with abstract builder
public abstract class Pizza {
    public enum Topping { HAM, MUSHROOM, ONION, PEPPER, SAUSAGE }
    final Set<Topping> toppings;
    
    // Abstract builder with recursive generic type parameter T
    abstract static class Builder<T extends Builder<T>> {
        EnumSet<Topping> toppings = EnumSet.noneOf(Topping.class);
        
        // Return this with appropriate subtype to allow method chaining
        public T addTopping(Topping topping) {
            toppings.add(topping);
            return self();
        }
        
        abstract Pizza build();
        
        // Subclasses must override this to return "this"
        protected abstract T self();
    }
    
    Pizza(Builder<?> builder) {
        toppings = builder.toppings.clone();
    }
}

// Concrete Pizza subclass with its Builder subclass
public class NYPizza extends Pizza {
    public enum Size { SMALL, MEDIUM, LARGE }
    private final Size size;
    
    // NYPizza.Builder extends Pizza.Builder with appropriate type
    public static class Builder extends Pizza.Builder<Builder> {
        private final Size size;
        
        public Builder(Size size) {
            this.size = size;
        }
        
        @Override public NYPizza build() {
            return new NYPizza(this);
        }
        
        @Override protected Builder self() {
            return this;
        }
    }
    
    private NYPizza(Builder builder) {
        super(builder);
        size = builder.size;
    }
}

// Usage example
NYPizza pizza = new NYPizza.Builder(Size.MEDIUM)
                          .addTopping(Topping.SAUSAGE)
                          .addTopping(Topping.ONION)
                          .build();

Key features:

• Builder<T extends Builder<T>> creates recursive type parameter
• self() method returns appropriate subtype to allow method chaining
• Each concrete class gets its own builder that extends the parent builder
• Builders know exactly what type they're building

Making a class a singleton impacts testability by:

• Making it impossible to substitute a mock implementation for testing
• Creating global state that persists between tests
• Causing tight coupling between the singleton and its clients
• Making parallel test execution difficult due to shared state

Alternative patterns for classes that need dependency injection:

1. Constructor Injection:

public class SpellChecker {
    private final Lexicon dictionary;
    
    public SpellChecker(Lexicon dictionary) {
        this.dictionary = Objects.requireNonNull(dictionary);
    }
    
    public boolean isValid(String word) { /* use dictionary */ }
}

2. Factory Method Injection:

public class SpellChecker {
    private final Lexicon dictionary;
    
    private SpellChecker(Lexicon dictionary) {
        this.dictionary = dictionary;
    }
    
    public static SpellChecker create(Lexicon dictionary) {
        return new SpellChecker(dictionary);
    }
}

3. Dependency Injection Framework (Spring, Guice, etc.):

@Service
public class SpellChecker {
    private final Lexicon dictionary;
    
    @Autowired
    public SpellChecker(Lexicon dictionary) {
        this.dictionary = dictionary;
    }
}

These approaches allow resources to be parameterized rather than hardwired, improving flexibility and testability.

Autoboxing in Java:

• Automatic conversion between primitive types and wrapper classes
• Enables mixing primitives and objects in expressions
• Happens implicitly when primitive is assigned to wrapper type

Performance issues:

// Performance problem due to autoboxing
private static long sum() {
    Long sum = 0L;  // Uses wrapper class instead of primitive
    for (long i = 0; i <= Integer.MAX_VALUE; i++) {
        sum += i;   // Each addition creates a new Long object
    }
    return sum;
}

This creates approximately 2³¹ unnecessary Long instances because:

• Each addition autoboxes the result into a new Long object
• Each iteration discards the previous Long object
• Creates massive unnecessary garbage collection overhead

Best practice solution:

// Efficient version using primitives
private static long sum() {
    long sum = 0L;  // Uses primitive type
    for (long i = 0; i <= Integer.MAX_VALUE; i++) {
        sum += i;   // Simple primitive operation, no boxing
    }
    return sum;
}

Key guidelines:

• Prefer primitives over boxed primitives for simple values
• Be vigilant about accidental autoboxing in performance-critical code
• Watch for subtle type differences (Long vs long) that can trigger autoboxing
• Use primitives for local variables, parameters, return types, and fields
• Only use wrapper types when required (generics, nullability, reflection)

Balancing "Avoid creating unnecessary objects" vs. "Eliminate obsolete references":

| Avoid Creating Unnecessary Objects | Eliminate Obsolete References | |-----------------------------------|-------------------------------| | Focus on performance optimization | Focus on preventing memory leaks | | Reuse objects to reduce GC overhead | Null out references to enable GC | | Example: Use string literals instead of constructors | Example: Null elements in arrays after use |

Balancing principles:

1. Prioritize correctness over optimization:

   • Always eliminate obsolete references when managing memory
   • Memory leaks cause correctness issues; performance is secondary

2. Context-specific application:

   • Avoid creating objects: Apply in hot loops, frequently called methods
   • Eliminate references: Apply in classes managing object pools/collections

3. Cost-benefit analysis:

   • Unnecessary objects: Performance cost is typically modest for small objects
   • Memory leaks: Costs can compound catastrophically over time

4. Decision framework:

   If class manages its own memory:
       → Always null out obsolete references
   Else if object creation is in performance-critical path:
       → Look for object reuse opportunities
   Else:
       → Favor code clarity over premature optimization
   

5. Defensive copying takes precedence:

   • When security or correctness requires defensive copies, make them
   • "Don't reuse an existing object when you should create a new one"
   • Security/correctness bugs from insufficient copying are worse than performance issues

Rule of thumb: The penalty for failing to eliminate obsolete references (memory leaks) is typically far greater than the penalty for creating unnecessary objects (performance hit).

Performance problem: The naive implementation creates a new Pattern object for each validation, which is expensive because it compiles the regex into a finite state machine each time.

// Inefficient implementation
static boolean isRomanNumeral(String s) {
    return s.matches("^(?=.)M*(C[MD]|D?C{0,3})"
        + "(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");
}

Issues:

• String.matches() internally creates a new Pattern instance each time
• Pattern compilation is computationally expensive
• The compiled Pattern becomes garbage after single use
• Performance impact multiplies with frequent method calls

Optimized solution: Compile the Pattern once and reuse it for all validations.

// Efficient implementation
public class RomanNumerals {
    // Compile pattern once and cache it as a class constant
    private static final Pattern ROMAN = Pattern.compile(
        "^(?=.)M*(C[MD]|D?C{0,3})(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");
    
    // Reuse the compiled pattern for each validation
    static boolean isRomanNumeral(String s) {
        return ROMAN.matcher(s).matches();
    }
}

Performance improvement:

• Compiles the regex only once at class initialization
• Pattern object is immutable and thread-safe
• Dramatically reduces CPU usage (6.5× faster in benchmarks)
• Eliminates unnecessary object creation and garbage collection
• Additional benefit: Names the pattern, improving code readability

Note: For truly optional patterns, consider lazy initialization, but this is generally unnecessary and complicates the code.

A State class used with cleaners must be static because:

1. Non-static nested classes hold implicit references to their enclosing class instance
2. If State were non-static, it would hold a reference to the enclosing Room instance
3. This reference would create a circularity: Room → Cleanable → State → Room
4. This circularity would prevent Room from ever becoming eligible for garbage collection
5. The very purpose of the cleaner (automatic cleanup) would be defeated

Similarly, you shouldn't use a lambda for the cleaning action because lambdas can easily capture references to enclosing objects, creating the same circularity problem.

Proper design ensures State only holds the minimal resources needed for cleanup with no reference to the containing object.

/**
 * Reads the first line from a file, returning a default value if anything goes wrong.
 * @param path Path to the file to read
 * @param defaultVal Value to return if reading fails
 * @return The first line of the file or defaultVal if an error occurs
 */
public static String firstLineOfFile(String path, String defaultVal) {
    try (BufferedReader br = new BufferedReader(new FileReader(path))) {
        return br.readLine();
    } catch (IOException e) {
        return defaultVal;
    }
}

Key features:

• try-with-resources ensures BufferedReader is always closed
• Single catch block handles all IOExceptions without nested try blocks
• Default value provided as parameter for flexibility
• Method never throws exceptions, simplifying caller code
• Clean and readable despite handling error cases
• If close() throws an exception after readLine() succeeds, that exception is suppressed in favor of returning the read value

Guidelines for proper native peer cleanup:

1. For critical resources or performance-sensitive code:

   • Implement AutoCloseable
   • Provide explicit close() method
   • Document that clients MUST call close()
   • Use try-with-resources in client code

2. For non-critical resources with acceptable performance impact:

   • Use a cleaner as primary cleanup mechanism
   • Consider if 500ns overhead per object is acceptable
   • Good for native resources that don't need immediate reclamation

3. For hybrid approach (recommended):

   • Implement AutoCloseable as primary mechanism
   • Use cleaner as safety net only
   • Performance cost: ~5x overhead vs. pure try-with-resources
   • Document that clients should still use try-with-resources

Implementation notes for native peers:

• Store native pointer (handle) in the State object
• Implement native cleanup code in State.run()
• Ensure native cleanup is idempotent (can be called multiple times safely)
• Consider tracking if already cleaned up to avoid unnecessary JNI calls

This approach provides balance between safety and performance.