Can You Add Additional Methods to a Record

Permitted method types include: 4. Wither Methods: For functional, immutable state transformation.

🟢 Junior Level

Yes, absolutely. In Java, a Record is a full-fledged class type, and you can declare any custom methods inside its body.

Permitted method types include:

Instance Methods: For calculating derived properties based on component fields.
Static Factory Methods: Such as of(...), empty(), or named builders.
Private Helper Methods: For internal algorithmic decomposition.
Wither Methods: For functional, immutable state transformation.

public record User(String firstName, String lastName, int age) {
    // 1. Instance method (derived property)
    public String fullName() {
        return firstName + " " + lastName;
    }

    // 2. Business predicate
    public boolean isAdult() {
        return age >= 18;
    }

    // 3. Static factory method
    public static User anonymous() {
        return new User("John", "Doe", 0);
    }
}

// Usage:
User user = new User("Alice", "Smith", 25);
System.out.println(user.fullName()); // "Alice Smith"
System.out.println(user.isAdult());  // true

The Primary Restriction

While you can add behavior (methods), you cannot add instance state (non-static instance fields). The entire state of a record must be declared exclusively within its header.

🟡 Middle Level

1. The Wither Pattern (Immutable State Evolution)

Because record components are final, classical mutable setter methods (setAge(int age)) are impossible. Instead, modern Java employs the Wither pattern: a method returns a new record instance with the target component updated:

public record Order(UUID id, BigDecimal total, OrderStatus status) {
    // Wither method: returns an updated copy with a new status
    public Order withStatus(OrderStatus newStatus) {
        return new Order(this.id, this.total, newStatus);
    }

    // Wither method: returns an updated copy with a recalculated total
    public Order withTotal(BigDecimal newTotal) {
        return new Order(this.id, newTotal, this.status);
    }
}

// Usage:
Order pending = new Order(UUID.randomUUID(), BigDecimal.valueOf(100), OrderStatus.PENDING);
Order paid = pending.withStatus(OrderStatus.PAID);

2. Overriding Canonical Methods

You can explicitly override standard synthesized methods:

toString(): To mask sensitive data (passwords, credit card numbers).
equals() and hashCode(): For specialized equality rules (e.g., case-insensitive strings or array content equality via Arrays.equals).
Accessor Methods: For defensive copying (e.g., Collections.unmodifiableList(items)).

public record CreditCard(String cardNumber, String holder, String cvv) {
    // Mask sensitive fields in toString to prevent log leakage:
    @Override
    public String toString() {
        return "CreditCard[holder=" + holder + ", cardNumber=****" + cardNumber.substring(cardNumber.length() - 4) + "]";
    }
}

🔴 Senior Level

Java Language Specification Constraints (JLS §8.10.2)

The Java Language Specification enforces strict rules on methods declared inside a record:

Native Methods are Forbidden:
```
public record NativeHolder(int value) {
    // public native void doLowLevelWork(); // ❌ Compilation error: native method not allowed in record
}
```
Rationale: Records are designed to be mathematically transparent, platform-independent data carriers. Native methods delegate implementation outside the JVM, conflicting with record semantics.

Component Signature Conflicts: You cannot declare a method matching a component’s name with an incompatible return type:

public record Point(int x, int y) {
    // public String x() { return "x=" + x; } // ❌ Error: incompatible return type with component x
}

Desynchronization Hazard When Overriding Accessors: If you override a component accessor:
```
public record User(String name) {
    public String name() {
        return name.toUpperCase(); // Normalized on read
    }
}
```
[!CAUTION] The compiler-synthesized equals() method accesses this.name directly in bytecode via getfield, bypassing the name() method. If u1 = new User("alice") and u2 = new User("ALICE"), then u1.name().equals(u2.name()) evaluates to true, but u1.equals(u2) evaluates to false! Always normalize data in the compact constructor during construction, never inside read accessors.

Architectural Role: Rich Value Objects vs. Anemic Models

Adding domain methods to a Record is an established best practice in Domain-Driven Design (DDD):

Encouraged: Pure functions calculating derived attributes (area(), fullName()), validation predicates (isExpired()), domain factories, and withers. This transforms records into rich, expressive Value Objects.
Strongly Discouraged: Injecting Spring services, performing blocking network/database I/O, or mutating external shared state. A record must remain a pure, transparent representation of its arguments.

4 Tricky Questions

1. Can a Record declare a native method (`public native void doSomething()`)?

Answer: No, native methods are strictly prohibited. According to JLS §8.10.2: “It is a compile-time error if a record declaration contains a native method”. Records are engineered as transparent, serializable, and easily optimizable data containers. Native methods bind behavior to machine-dependent C/C++ code via JNI, violating transparency and platform neutrality.

2. How do you implement non-destructive mutation for a single field in a Record (the Wither pattern)?

Answer: Because record components are immutable (private final), classical mutator setters are impossible. The Wither pattern is used instead: a method prefixed with with... takes the replacement value for one component and invokes the canonical constructor, forwarding all other unchanged components:

public record Account(UUID id, BigDecimal balance, boolean active) {
    public Account withBalance(BigDecimal newBalance) {
        return new Account(this.id, newBalance, this.active);
    }
}

This preserves thread safety and immutability. In future Java versions (Project Amber), dedicated language-level with expressions are planned.

3. What subtle consistency bug occurs if you override a component accessor to transform data (e.g. `return name.toLowerCase()`)?

Answer: The code compiles, but it breaks equals() consistency. The compiler-generated equals() and hashCode() methods read the private field this.name directly using bytecode getfield instructions rather than invoking the accessor method this.name(). If u1 = new User("ALICE") and u2 = new User("alice"), calling u1.name().equals(u2.name()) returns true, but u1.equals(u2) returns false! Data normalization must always occur in the compact constructor so that the underlying field itself stores the normalized value.

4. Can you overload a component accessor method in a Record (e.g. `public String name(String prefix)`)?

Answer: Yes, you can. In Java, method overloading is based on the full method signature (name plus parameter types). The method public String name(String prefix) has a different parameter list than the zero-argument canonical accessor public String name(). The compiler treats it as a standard custom instance method without conflict.

🎯 Interview Cheat Sheet

Summary in 60 Seconds

Allowed Methods:
- Arbitrary instance methods (public, protected, package-private, private).
- Static factory methods and constants (public static of(...)).
- Wither methods (with...) for functional updates.
- Custom overrides of equals(), hashCode(), toString(), and accessors.
Prohibited Constructs:
- Non-static instance fields in the body.
- Native methods (native keyword).
- Altering the return type of component accessors.
DDD Value Object: Records should encapsulate derived domain calculations, but never perform external I/O or service calls.

Common Interview Traps

Normalizing data inside an accessor method rather than in the compact constructor (causes equals() desynchronization).
Attempting to declare setter methods (public void setX(...)).
Injecting Spring beans or DAOs into a Record.