Java Coding Guide

Problem

Everyday Java code carries risks that are not only style: unbounded pools from Executors, shared SimpleDateFormat, money arithmetic with double, unsalted MD5 password storage, Optional.get() without a safe accessor, and Random used for tokens or sequence numbers can all become production incidents. A bigger issue is repeated dependency decisions during code generation: whether to use Hutool or commons-lang3, WebClient or OkHttp in a Spring project, and whether var is allowed on JDK 8. This guide compresses those questions into enforceable conventions: stack neutrality, one default per domain, and version gating.

How It Works

On activation, it performs stack detection: it reads pom.xml / build.gradle to confirm the target JDK and existing dependencies in one pass, such as Spring, Hutool, commons-lang3, Guava, Jackson, OkHttp, Lombok, or MapStruct. If an equivalent library already exists, it follows that library and avoids mixing multiple string or collection utilities in one project. Low-risk gaps default to JDK built-ins; high-risk gaps such as crypto or Bean mapping trigger one confirmation about adopting a mature component or using a controlled handwritten fallback.

Before generating code, it routes by “domain → default” and reads the relevant reference for null/string, collection/stream, date/time, IO/HTTP/JSON, concurrency, object mapping, crypto, exception/logging, modern Java, BigDecimal, naming conventions, and complexity control. Rules are split into S-level and A-level: S-level items are bug- or incident-level prohibitions and should be raised when existing code is reviewed or modified; A-level items constrain only newly generated code. JDK features are gated by minimum version, for example var requires 10+, sealed requires 17+, and virtual threads require 21+, so JDK 8 projects must stay below those boundaries.

Boundaries

It is best for code generation, review, and modification constraints in Java projects that already have a known stack. It does not force dependency replacement. Spring projects should prefer Spring-native capabilities; pure Java projects should prefer JDK built-ins or mature components per domain. It does not include preview or incubator features and does not invent library choices without project evidence. If a user declines a high-risk dependency, output may fall back to handwritten code, but it must preserve the referenced guards, such as disallowing unsalted passwords and padding hex output, with a comment marking the controlled fallback.