1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
# Java
Use this note for Java source scopes. It sharpens the generic extermination pass; it is not a style guide.
## Manifest
Source files are `*.java` under the requested subtree. Exclude generated sources, vendored code, build output, fixtures, snapshots, and annotation-processor products unless the user explicitly includes them. Include tests when they expose duplicated construction, domain shape, or behavior-preservation evidence.
## Navigation
Use the project's Java language server, IDE metadata, Maven/Gradle graph, and textual search together. Anchor from live use sites: constructor calls, factory methods, getters/setters, switch sites, serialization boundaries, mapper layers, repository methods, validator calls, and DTO/domain conversions. Java's indirection is often architectural sediment; chase references until the real owner is visible.
## Modernization Posture
Do not preserve legacy Java style as a virtue. Use the latest Java version supported by the project unsparingly, and treat unjustified old language-level pins as slop to question. Prefer records, sealed hierarchies, switch expressions, pattern matching, compact constructors, local type inference, immutable collections, and modern standard-library APIs when they collapse boilerplate or make states explicit. If the build cannot move to the current language level, record that constraint instead of silently writing Java 8-shaped code.
## Deslopping Moves
Move semantics out of strings, maps, nulls, telescoping constructors, and mutable JavaBeans. Domain data with stable identity or invariants wants records, value objects, enums, sealed interfaces, or small final classes with validating constructors. Finite state spaces want enums or sealed hierarchies, not strings, integer codes, nullable fields, or parallel booleans. Repeated argument groups and DTO shuttles want named domain carriers.
Collapse repeated parse, validate, normalize, map, format, authorize, query, and error-shaping logic into one owner. Prefer total constructors/factories, enum behavior, sealed dispatch, shared mappers, and narrow modules over duplicated service-layer folklore. Delete getter/setter husks, pointless adapters, ceremonial builders, redundant DTO twins, and compatibility layers unless an external boundary truly requires them.
Bias toward code volume reduction when it increases semantic density. A record replacing a class wall, a sealed hierarchy replacing flag fields, or one domain mapper replacing five hand-written conversions is the correct direction. Do not mistake verbosity for enterprise seriousness.
## Java-Specific Suspects
Scrutinize `String` identifiers/statuses/types, `Map<String, Object>`, raw or weak generics, nullable fields, `Optional` fields, boolean constructor parameters, Lombok masking structure, mutable bean DTOs, anemic service methods, repeated mapper code, exception wrapping boilerplate, duplicated validation annotations plus manual checks, and switch/if chains over the same discriminator.
Scrutinize boundaries separately. JSON, SQL, Kafka, REST, GraphQL, CLI, and legacy API surfaces may need primitive or DTO shapes externally, but convert to domain types at the boundary. Do not let transport classes become the internal model.
## Verification
After edits, run the narrowest meaningful Maven or Gradle compile/test command for the touched module, then widen if the abstraction crosses modules. Include formatter/checkstyle/spotbugs/error-prone/nullness checks when they are part of the repo contract, but never treat them as a substitute for the extermination ledger.
## Avoid
Do not write new Java in a legacy idiom unless the toolchain forces it. Do not preserve mutability, nullability, beans, builders, or DTO duplication by default. Do not add abstraction whose invariant is imaginary. Do not leave five verbose repetitions because the one modern representation feels unfamiliar.
|