Classes and Interfaces

A security vulnerability can arise when:

1. A subclass overrides methods that add elements to enforce validation rules
2. The superclass later adds a new method capable of inserting elements
3. This new method is not overridden in the subclass
4. The new method can be used to bypass validation completely

This exact problem required security fixes when Hashtable and Vector were retrofitted to participate in the Collections Framework. It demonstrates why inheritance creates fragile dependencies on superclass implementation details.

The SELF problem (Self-Encapsulation Loss Failure) occurs in wrapper classes when:

1. The wrapped object doesn't know about its wrapper
2. The wrapped object passes a reference to itself (this) to other objects
3. These callbacks bypass the wrapper completely, going directly to the wrapped object

Example: If a wrapped collection notifies listeners of changes, it passes its own reference (this) rather than the wrapper's reference, causing subsequent callbacks to miss any additional functionality provided by the wrapper.

This limitation makes wrapper classes unsuitable for callback frameworks where objects pass self-references to other objects for subsequent invocations.

Two implicit module-based access levels:

1. Module-private public members: Public and protected members of public classes in unexported packages
2. Module-private protected members: Protected members of public classes in unexported packages

Limitations of utility:

1. Advisory nature: If you place a module's JAR on the classpath (not module path), these restrictions disappear
2. Implementation complexity: Requires grouping packages into modules, explicit module declarations, source tree reorganization
3. Compatibility challenges: Requires special handling for access to non-modularized packages
4. Limited adoption: Not widely used outside the JDK itself
5. Learning curve: Adds complexity compared to traditional access control mechanisms

Practical implication: Most Java programmers should focus on the four traditional access levels (private, package-private, protected, public) unless there's a compelling need for module encapsulation.

Current recommendation: Avoid relying on module-based access levels unless specifically needed for large systems with clear module boundaries.

Refactoring approach:

Convert the package-private top-level class into a private static nested class of the sole class that uses it.

Implementation steps:

1. Move the class definition inside its sole client class
2. Make the nested class private to restrict access
3. Make it static if it doesn't need access to enclosing instance members
4. Adjust any package-private members as needed

Before refactoring:

// Original package-private class in same package as Client
class Helper {
    void helperMethod() { /* implementation */ }
}

public class Client {
    void method() {
        Helper helper = new Helper();
        helper.helperMethod();
    }
}

After refactoring:

public class Client {
    // Nested inside the only class that needs it
    private static class Helper {
        void helperMethod() { /* implementation */ }
    }
    
    void method() {
        Helper helper = new Helper();
        helper.helperMethod();
    }
}

Benefits:

• Reduces accessibility from all classes in package to just one class
• Makes the helper-client relationship explicit in the code structure
• Improves encapsulation by minimizing exposure
• Simplifies maintenance by co-locating related functionality
• Provides clearer code organization for future developers

Functional Approach: Methods return the result of applying a function to operands without modifying them.

Characteristics:

• Creates new objects as results instead of modifying existing ones
• Methods named as prepositions (e.g., plus) rather than verbs (e.g., add)
• Objects remain immutable
• No side effects

Example - Functional Approach (Complex class):

public Complex plus(Complex c) {
    return new Complex(re + c.re, im + c.im);
}
// Used as: Complex sum = a.plus(b);  // a and b unchanged

Procedural/Imperative Approach: Methods modify the state of the object they operate on.

Characteristics:

• Modifies objects in-place
• Methods named as verbs (e.g., add)
• Objects are mutable
• Has side effects

Example - Procedural Approach (StringBuilder):

public StringBuilder append(String str) {
    // Modifies internal state
    // Implementation details...
    return this;
}
// Used as: sb.append("text");  // sb is modified

The functional approach enables immutability, thread safety, and simpler reasoning about code, while the procedural approach can be more efficient for operations requiring multiple steps by avoiding intermediate object creation.

Key relaxation: Using non-final fields for caching expensive computations while maintaining logical immutability.

This technique:

1. Maintains logical immutability (no externally visible state changes)
2. Uses non-final fields to cache expensive computation results
3. Implements lazy initialization for optimized performance

Implementation example with lazy hash code computation:

public final class PhoneNumber {
    private final short areaCode, prefix, lineNum;
    
    // Non-final field for caching hash code
    private int hashCode; // Automatically initialized to 0
    
    // Constructor and other methods...
    
    @Override public int hashCode() {
        // Lazy initialization of cached hash code
        int result = hashCode;
        if (result == 0) {
            result = 31 * Short.hashCode(areaCode);
            result = 31 * result + Short.hashCode(prefix);
            result = 31 * result + Short.hashCode(lineNum);
            hashCode = result; // Cache for future calls
        }
        return result;
    }
}

This works because:

• The cached value is computed from immutable state, so it never changes
• The field is only modified during first access, and all threads will compute the same value
• Subsequent calls avoid expensive recomputation
• No externally visible state change occurs

String, BigInteger and other immutable classes use this technique for performance optimization while maintaining the benefits of immutability.

To maintain true immutability when an immutable class contains references to mutable objects:

1. During construction:

   • Defensively copy all mutable inputs
   • Never store references to client-provided mutable objects

2. In accessors:

   • Never return references to internal mutable objects
   • Return defensive copies of mutable internal components

3. For serialization:

   • Implement readObject and readResolve methods
   • Or use ObjectOutputStream.writeUnshared and ObjectInputStream.readUnshared

Example with serialization handling:

public final class ImmutableHolder implements Serializable {
    private final Date date; // Mutable!
    
    public ImmutableHolder(Date date) {
        // Defensive copy in constructor
        this.date = new Date(date.getTime());
    }
    
    public Date getDate() {
        // Defensive copy in accessor
        return new Date(date.getTime());
    }
    
    // Serialization protection
    private void readObject(ObjectInputStream s) throws IOException, ClassNotFoundException {
        s.defaultReadObject();
        
        // Validate potentially corrupt deserialized state
        if (date == null) {
            throw new InvalidObjectException("Date cannot be null");
        }
    }
    
    // Prevent replacing with malicious subclass during deserialization
    private Object readResolve() {
        // Create a new instance with the deserialized state
        return new ImmutableHolder(date);
    }
}

Serialization precautions are necessary because:

1. Deserialization can create objects without calling constructors
2. An attacker could create a malicious byte stream that produces mutable instances
3. Subclasses might be substituted during deserialization

Without these precautions, attackers could potentially create mutable instances of your supposedly immutable class.

Rule: Constructors must never invoke overridable methods, either directly or indirectly.

If violated:

1. The superclass constructor runs before the subclass constructor
2. If the superclass constructor calls an overridable method, the subclass version will be called
3. But the subclass constructor hasn't run yet, so its instance fields are uninitialized
4. Fields will be in their default state (null for objects, 0 for numeric types, etc.)

Example:

class Super {
    public Super() {
        overrideMe(); // Dangerous! Calls subclass version before subclass constructor runs
    }
    public void overrideMe() {}
}

class Sub extends Super {
    private final Instant instant;
    
    Sub() {
        instant = Instant.now(); // This runs AFTER overrideMe() is called!
    }
    
    @Override public void overrideMe() {
        System.out.println(instant); // Prints "null", not the initialized value
    }
}

This violates proper object construction semantics, causing bugs that are difficult to diagnose.

Restrictions:

1. Neither clone() nor readObject() may invoke an overridable method, directly or indirectly
2. The same restriction applies to constructors

Rationale:

• Both methods function like constructors in that they create new objects
• During cloning or deserialization, the object may be in a partially initialized state
• If they call an overridable method, the overriding method in the subclass will execute
• The subclass's method may depend on initialization not yet performed

Example with clone():

public class Super implements Cloneable {
    @Override public Super clone() {
        Super result = (Super) super.clone();
        overrideMe();  // DANGEROUS! Will call subclass method when subclass is cloned
        return result;
    }
    
    public void overrideMe() {}
}

public class Sub extends Super {
    private final List<String> list;
    
    public Sub() {
        list = new ArrayList<>();
    }
    
    @Override public void overrideMe() {
        list.add("element");  // NPE if called from Super.clone() before Sub's fields are initialized
    }
}

A forwarding class improves the composition pattern by:

1. Separating the forwarding logic from the enhanced functionality
2. Creating a reusable component that implements all forwarding methods for an interface
3. Reducing duplication when multiple wrapper classes are needed for the same interface

Implementation example:

// Reusable forwarding class
public class ForwardingSet<E> implements Set<E> {
    private final Set<E> s;
    public ForwardingSet(Set<E> s) { this.s = s; }
    
    // Forward all Set methods to the wrapped set
    public boolean add(E e) { return s.add(e); }
    public boolean remove(Object o) { return s.remove(o); }
    public int size() { return s.size(); }
    // ... and so on for all methods
}

// Specific wrapper that extends the forwarding class
public class InstrumentedSet<E> extends ForwardingSet<E> {
    private int addCount = 0;
    
    public InstrumentedSet(Set<E> s) {
        super(s);
    }
    
    @Override public boolean add(E e) {
        addCount++;
        return super.add(e);
    }
    
    @Override public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return super.addAll(c);
    }
    
    public int getAddCount() {
        return addCount;
    }
}

Specific advantage: When creating multiple wrapper classes for the same interface (e.g., SynchronizedSet, InstrumentedSet, UnmodifiableSet), the forwarding class needs to be written only once, and each wrapper only needs to implement the methods it wishes to enhance.