Spring Boot Prompt for Java Records & Sealed Interface Patterns

What this prompt does

This prompt asks the AI to refactor a [domain] Java [java_version] application toward modern language features so illegal states become unrepresentable. It introduces records for immutable value objects ([value_objects]), sealed interfaces for the [sealed_hierarchies] with exhaustive switch expressions, pattern matching for instanceof with deconstruction, record patterns in switch for [switch_use_case], compact constructors with validation, record-based DTOs replacing POJOs with a shown migration, a sealed-interface Result<T, E> type for error handling without exceptions, Jackson serialization of sealed hierarchies, record projections for JPA, and unit tests verifying immutability, equals/hashCode, and switch exhaustiveness.

The structure works because records and sealed hierarchies let the compiler enforce correctness: an exhaustive switch over a sealed type fails to compile if you miss a case, and a Result type makes error handling explicit instead of relying on thrown exceptions. Grounding the work in your real [value_objects] and [sealed_hierarchies] keeps it a genuine refactor rather than a feature tour. Compact constructors carry their weight here as well, validating invariants at construction time so an invalid value object cannot exist in the first place, which removes a layer of defensive checks elsewhere in the code.

When to use it

• You are modeling a domain where some types form a closed set and you want exhaustive handling enforced.
• You want immutable value objects ([value_objects]) as records instead of mutable POJOs.
• You want pattern matching and record deconstruction to replace chains of instanceof and casts.
• You prefer explicit error handling via a Result type over exceptions for expected failures.
• You are migrating DTOs to records and want a clear before/after path.
• You want tests that verify immutability and that switches stay exhaustive as the hierarchy grows.

Example output

Expect record definitions for [value_objects] with compact-constructor validation, sealed interfaces for [sealed_hierarchies] with exhaustive switches, pattern-matching examples including record patterns for [switch_use_case], a Result<T, E> type, the POJO-to-record DTO migration, Jackson configuration for the sealed hierarchies, JPA record projections, and unit tests. It reads as a guided modernization of real code rather than isolated snippets.

Pro tips

• List [value_objects] that are genuinely immutable (Money, AccountId, DateRange); records fit values, not entities with identity and lifecycle.
• Define [sealed_hierarchies] as truly closed sets so exhaustive switches are meaningful and the compiler can enforce them.
• Match [java_version] to your runtime, since record patterns and sealed-type support vary across recent Java releases.
• Use compact constructors to validate invariants at construction, so an invalid value object simply cannot exist.
• Keep records out of JPA entities and use them as projections instead, as the prompt does, since records do not fit Hibernate's entity lifecycle.
• Iterate by asking it to model one specific hierarchy from [sealed_hierarchies] end to end, including the Jackson round-trip.