How do I use record with generics?

Using records with generics in Java allows you to create immutable data structures while also providing the benefits of generics, such as type safety and flexibility. Since Java 16, the record feature was introduced, and it can be combined with generics like other classes. Here’s an example of how to use records with generics.

Syntax

To define a record with generics, you specify the type parameter(s) in the record declaration just like in a class declaration.

public record MyRecord<T>(T value) { }

Examples

1. Basic Generic Record

A simple record that accepts a generic type parameter:

// Define record with a generic parameter T
public record Box<T>(T content) { }

Usage:

public class Main {
    public static void main(String[] args) {
        // Create a record with a String type
        Box<String> stringBox = new Box<>("Hello, generics!");
        System.out.println(stringBox.content()); // Output: Hello, generics!

        // Create a record with an Integer type
        Box<Integer> integerBox = new Box<>(123);
        System.out.println(integerBox.content()); // Output: 123
    }
}

2. Records with Multiple Generics

You can define records with multiple type parameters, just like generic classes:

// Define a record with two generic types
public record Pair<K, V>(K key, V value) { }

Usage:

public class Main {
    public static void main(String[] args) {
        // Create a Pair with String and Integer
        Pair<String, Integer> pair = new Pair<>("Age", 30);
        System.out.println(pair.key() + ": " + pair.value()); // Output: Age: 30

        // Create a Pair with two different types
        Pair<Double, String> anotherPair = new Pair<>(3.14, "Pi");
        System.out.println(anotherPair.key() + " -> " + anotherPair.value()); // Output: 3.14 -> Pi
    }
}

3. Generics with Constraints

Generic records can include bounded type parameters to restrict the types allowed:

// Generic type T is constrained to subclasses of Number
public record NumericBox<T extends Number>(T number) { }

Usage:

public class Main {
    public static void main(String[] args) {
        // Only Number or subclasses of Number are allowed
        NumericBox<Integer> intBox = new NumericBox<>(42);
        System.out.println(intBox.number()); // Output: 42

        NumericBox<Double> doubleBox = new NumericBox<>(3.14);
        System.out.println(doubleBox.number()); // Output: 3.14

        // Compiler error: String is not a subclass of Number
        // NumericBox<String> stringBox = new NumericBox<>("Not a number");
    }
}

4. Working with Wildcards

You can use wildcards in generic records when specifying their types:

public class Main {
    public static void main(String[] args) {
        // Using a wildcard
        Box<?> anyBox = new Box<>("Wildcard content");
        System.out.println(anyBox.content()); // Output: Wildcard content

        // Using bounded wildcards
        NumericBox<? extends Number> numBox = new NumericBox<>(42);
        System.out.println(numBox.number()); // Output: 42
    }
}

Benefits of Using Generics with Records

  1. Type Safety: With generics, the compiler ensures the record is used correctly for the intended type.
  2. Reusability: You can use the same record with different data types.
  3. Immutability: Records’ inherent immutability, coupled with generics, allows you to encapsulate type-safe, immutable data structures.

This approach works seamlessly with the other features of records, such as pattern matching and compact constructors. Let me know if you’d like more advanced scenarios!

How do I use compact constructors in records?

Compact constructors in records are a concise way to initialize and validate fields of a record in Java. Unlike standard constructors, compact constructors omit the parameter list, as they operate directly on the record’s declared components.

Here’s how to use compact constructors in records:

1. Syntax:

A compact constructor is declared without parentheses after the constructor name. Inside the constructor body, you can initialize or validate fields of the record.

Example:

public record Person(String name, int age) {
    // Compact constructor
    public Person {
        if (name == null || name.isBlank()) {
            throw new IllegalArgumentException("Name cannot be null or blank");
        }
        if (age < 0) {
            throw new IllegalArgumentException("Age cannot be negative");
        }
    }
}

2. How It Works:

  • The compact constructor implicitly takes all the components of the record as parameters.
  • You can directly access these fields without explicitly specifying them as parameters since they are already “properties” of the record.
  • Unlike regular constructors, compact constructors aim to reduce boilerplate validations and/or additional initialization.

In the above example:

  • name and age are automatically initialized in the generated constructor, but the compact constructor validates them before allowing that to happen.
  • If the validations fail, the constructor throws exceptions.

3. Special Notes:

  • The Java compiler ensures that the compact constructor assigns values to all record components before the constructor completes execution.
  • You cannot directly modify the record components since they are implicitly final. What you can do is validate or make use of the incoming values.

4. Why Use Compact Constructors?

Compact constructors are helpful when:

  1. You need to validate fields during record initialization.
  2. You want to add extra logic (like logging) to the generated canonical constructor of the record.
  3. You want to reduce boilerplate by avoiding redundant parameter declarations.

5. Example with Additional Fields:

If the record has additional fields beyond what is declared in the record header, those can also be initialized in the compact constructor:

public record Rectangle(int length, int width) {
    private static final int MINIMUM_SIZE = 1;

    public Rectangle {
        // Validation
        if (length < MINIMUM_SIZE || width < MINIMUM_SIZE) {
            throw new IllegalArgumentException("Dimensions must be at least " + MINIMUM_SIZE);
        }
    }
}

Summary:

Compact constructors in records:

  • Automatically operate on the fields declared as record components.
  • Reduce boilerplate for constructor declarations.
  • Are ideal for validation and pre-processing logic.
  • Must initialize or ensure that all components are correctly set before completing.

How do I use sealed classes to control inheritance?

In Java, sealed classes are a feature introduced in Java 15 (as a preview and finalized in Java 17) that allows you to control inheritance by specifying which classes or interfaces can extend or implement a given class or interface. This makes your class hierarchy more predictable and easier to reason about.

Using sealed classes involves the following key concepts:

1. Declaration of a Sealed Class

A class can be declared as sealed, which means that only a specific set of classes (declared permits) can extend that class. Here’s the basic syntax:

public sealed class ParentClass permits ChildA, ChildB {
    // Class code
}

Here, only ChildA and ChildB (declared in permits) are allowed to extend ParentClass. This ensures complete control over the inheritance structure of your class.


2. The Role of Permitted Subclasses

Each subclass specified in the permits clause must do one of the following to complete the sealed hierarchy:

  • Declare itself as final (no further inheritance is allowed).
  • Declare itself as sealed (allowing further controlled inheritance).
  • Declare itself as non-sealed (allowing unrestricted inheritance).

Examples of each:

Final Subclass:

public final class ChildA extends ParentClass {
    // Class code
}

Sealed Subclass:

public sealed class ChildB extends ParentClass permits GrandChild {
    // Class code
}

public final class GrandChild extends ChildB {
    // Class code
}

Non-Sealed Subclass:

public non-sealed class ChildC extends ParentClass {
    // Class code
}

In the case of non-sealed, ChildC and its subclasses can be freely inherited, bypassing the restrictions of sealing.


3. Key Features and Benefits of Sealed Classes

  1. Ensure Complete Class Hierarchy Control:
    • By listing all allowed subclasses, you can restrict who can build upon your functionality.
    • Simplifies reasoning about the class hierarchy in complex systems.
  2. Improved Exhaustiveness Checking:
    • When used with instanceof or switch expressions, the compiler knows all the possible subclasses (because they’ve been explicitly listed).
    • For example, pattern matching with switch:
    public String process(ParentClass obj) {
         return switch (obj) {
             case ChildA a -> "ChildA";
             case ChildB b -> "ChildB";
             default -> throw new IllegalStateException("Unexpected value: " + obj);
         };
     }
    
  3. Enforces Encapsulation and API Design Consistency:
    • Encourages developers to think hard about which subclasses make sense.
  4. Useful for Modeling Closed Systems:
    • Great for scenarios where the possible subclasses represent a closed set of types, such as states in a state machine.

Example: Sealed Class for a Shape Hierarchy

Here is a practical example of using sealed classes in a geometric shape hierarchy:

public sealed class Shape permits Circle, Rectangle, Square {
    // Common shape fields and methods
}

public final class Circle extends Shape {
    // Circle-specific fields and methods
}

public final class Rectangle extends Shape {
    // Rectangle-specific fields and methods
}

public final class Square extends Shape {
    // Square-specific fields and methods
}

If someone tries to create a new subclass of Shape outside of those specified in permits, a compilation error will occur.


4. Rules and Restrictions

  • A sealed class must use the permits clause unless all permitted implementations are within the same file.
  • The permitted classes must extend the sealed class or implement the sealed interface.
  • Subclasses of sealed classes located in different packages must be public.
  • All permitted classes are resolved at compile time.

Summary

Java’s sealed classes provide you with a powerful tool to control inheritance in your programs by explicitly defining the classes that are allowed to extend or implement a particular class or interface. They make your code more robust, predictable, and maintainable by restricting which subclasses can exist in a hierarchy. Use them when you want tight control over a class hierarchy or when modeling scenarios with a limited set of possibilities.

How do I use enhanced instanceof pattern matching?

Enhanced instanceof pattern matching, introduced in Java 16 (as a preview feature) and finalized in Java 17, allows you to combine type checking with type casting, reducing boilerplate code and making it more concise and readable.

Here’s how you can use enhanced instanceof pattern matching:

  1. Basic Usage:
    Instead of separately checking if an object is an instance of a class and then casting it, you can do both in one step using the pattern matching feature. The syntax is:

    if (obj instanceof Type variableName) {
       // variableName is automatically cast to Type
    }
    

    Example:

    Object obj = "Hello, Java!";
    
    if (obj instanceof String str) { // This checks and casts obj to String
       System.out.println("String length: " + str.length());
    } else {
       System.out.println("Not a string.");
    }
    

    This eliminates the need for explicit type casting.

  2. Combine with Logical Operators:
    You can combine the pattern matching with additional conditions using logical operators like && or ||.

    Example:

    Object obj = "Patterns in Java";
    
    if (obj instanceof String str && str.length() > 10) {
       System.out.println("String is longer than 10 characters: " + str);
    } else {
       System.out.println("String is too short or not a string at all.");
    }
    

    In this case, the str variable is only in scope if both conditions are true.

  3. Scope of the Pattern Variable:

    • The pattern variable (e.g., str in the examples above) is only accessible within the block where the pattern matching is true.
    • Outside of the if block, the variable doesn’t exist.
  4. Negating with !instanceof:
    Pattern matching itself cannot be negated directly (no “not instanceof”), but you can invert the condition like this:

    if (!(obj instanceof String)) {
       System.out.println("Not a string.");
    }
    
  5. Using Pattern Matching in switch:
    Starting from Java 17 (as a preview) and improved in later versions, you can use pattern matching in switch statements for more powerful expressions. For example:

    Object obj = "Java 17";
    
    switch (obj) {
       case String str && str.length() > 5 -> System.out.println("Long string: " + str);
       case String str -> System.out.println("Short string: " + str);
       default -> System.out.println("Not a string.");
    }
    

    This allows a combination of pattern matching and conditionals directly within switch.


Benefits of Enhanced instanceof Pattern Matching

  • Reduction of Boilerplate Code: By avoiding explicit casting and declaring new variables.
  • Improved Readability: Simplifies conditional checks by combining the instance check and cast in one step.
  • Type Safety: Provides better compile-time safety for the variables you use after a cast.

Recap of the Code Features

From the files you’ve referenced:

  1. PatternMatchingExample.java demonstrates simple pattern matching with instanceof, where the type check and assignment are done in one step.
  2. PatternMatchingExampleCombine.java shows combining pattern matching with additional conditions (e.g., &&).

Both examples illustrate the practical and concise approach to type checking and casting introduced via enhanced instanceof pattern matching.

How do I use switch expressions introduced in Java 14+?

The switch expression, introduced in Java 12 (as a preview feature) and became a standard feature in Java 14, provides a more concise and powerful way to use switch statements. Here’s how to use it effectively:

Key Features of Switch Expressions

  1. Simpler Syntax: The new syntax allows the use of the -> syntax to eliminate fall-through behavior.
  2. Expression Form: The switch can now return a value directly.
  3. Multiple Labels: Multiple case labels can share the same logic using a comma-separated list.
  4. No More Breaks: No need for the break keyword after each case.

Syntax for Switch Expressions

Here’s a quick breakdown:

String dayType = switch (dayOfWeek) {
    case "Monday", "Tuesday", "Wednesday", "Thursday", "Friday" -> "Weekday";
    case "Saturday", "Sunday" -> "Weekend";
    default -> throw new IllegalArgumentException("Invalid day: " + dayOfWeek);
};

Explanation:

  • The -> syntax replaces the colon and break of the traditional switch.
  • default acts as a fallback for unmatched cases.
  • The result of the switch is assigned directly to the variable dayType.
  • Multiple cases separated by commas handle identical conditions.

Examples of Switch Expressions

Return a Value Directly from switch

int month = 3;
int daysInMonth = switch (month) {
    case 1, 3, 5, 7, 8, 10, 12 -> 31;
    case 4, 6, 9, 11 -> 30;
    case 2 -> 28; // Use 29 for leap years, this is simplified.
    default -> throw new IllegalArgumentException("Invalid month: " + month);
};
System.out.println("Days in Month: " + daysInMonth);

Using Code Blocks in a Case

For more complex logic, you can use curly braces {} to group multiple statements into a block. In such cases, you must use the yield keyword to specify a value to be returned.

String grade = "B";
String feedback = switch (grade) {
    case "A", "B" -> "Great job!";
    case "C", "D" -> {
        System.out.println("Encouraging message for grade: " + grade);
        yield "Needs improvement.";
    }
    case "F" -> "Failed.";
    default -> throw new IllegalArgumentException("Unknown grade: " + grade);
};
System.out.println("Feedback: " + feedback);

Advantages Over Traditional switch

  1. No Fall-Through: Avoid accidentally executing multiple cases (common bug with traditional switch).
  2. Cleaner Syntax: Easier to read and write due to the arrow operator (->) and elimination of break.
  3. Enhanced Type Safety: The returned value must match the expected type assigned to the variable.
  4. Pattern Matching (Java 17+): Future extensions allow switch with pattern matching for richer capabilities.

Use Cases

  1. Assigning values directly with clear logic.
  2. Simplifying code structure for multiple conditions or enums.
  3. Handling complex branching logic.