Java coding standards for Spring Boot and Quarkus services: naming, immutability, Optional usage, streams, exceptions, generics, CDI, reactive patterns, and project layout. Automatically applies framework-specific conventions. Use when writing or reviewing Java in a Spring Boot or Quarkus service.

Java Coding Standards Standards for readable, maintainable Java (17+) code in Spring Boot and Quarkus services. When to Use Writing or reviewing Java code in Spring Boot or Quarkus projects Enforcing naming, immutability, or exception handling conventions Working with records, sealed classes, or pattern matching (Java 17+) Reviewing use of Optional, streams, or generics Structuring packages and project layout [QUARKUS] : Working with CDI scopes, Panache entities, or reactive pipelines How It Works Framework Detection Before applying standards, determine the framework from the build file: Build file contains quarkus → apply [QUARKUS] conventions Build file contains spring boot → apply [SPRING] conventions Neither detected → apply shared conventions only Core Principles Prefer clarity over cleverness Immutable by default; minimize shared mutable state Fail fast with meaningful exceptions Consistent naming and package structure [QUARKUS] : Favor build time over runtime processing; avoid runtime reflection where possible Examples The sections below show concrete Spring Boot, Quarkus, and shared Java examples for naming, immutability, dependency injection, reactive code, exceptions, project layout, logging, configuration, and tests. Naming Immutability Optional Usage Streams Best Practices Dependency Injection Reactive Patterns [QUARKUS] Exceptions Use unchecked exceptions for domain errors; wrap technical exceptions with context Create domain specific exceptions (e.g., MarketNotFoundException ) Avoid broad catch (Exception ex) unless rethrowing/logging centrally Centralised Exception Handling Generics and Type Safety Avoid raw types; declare generic parameters Prefer bounded generics for reusable utilities Project Structure [SPRING] Maven/Gradle [QUARKUS] Maven/Gradle Formatting and Style Use 2 or 4 spaces consistently (project standard) One public top level type per file Keep methods short and focused; extract helpers Order members: constants, fields, constructors, public methods, protected, private Code Smells to Avoid Long parameter lists → use DTO/builders Deep nesting → early returns Magic numbers → named constants Static mutable state → prefer dependency injection Silent catch blocks → log and act or rethrow [QUARKUS] : @Singleton where @ApplicationScoped is intended — breaks proxying and interception [QUARKUS] : Mixing quarkus resteasy reactive and quarkus resteasy (classic) — pick one stack [QUARKUS] : Panache active record + repository pattern in the same bounded context — pick one Logging Null Handling Accept @Nullable only when unavoidable; otherwise use @NonNull Use Bean Validation ( @NotNull , @NotBlank ) on inputs [QUARKUS] : Apply @Valid on @BeanParam , @RestForm , and request body parameters Configuration Testing Expectations Shared JUnit 5 + AssertJ for fluent assertions Mockito for mocking; avoid partial mocks where possible Favor deterministic tests; no hidden sleeps [SPRING] @WebMvcTest for controller slices, @DataJpaTest for repository slices @SpringBootTest reserved for full integration tests @MockBean for replacing beans in Spring context [QUARKUS] Plain JUnit 5 + Mockito for unit tests (no @QuarkusTest ) @QuarkusTest reserved for CDI integration tests @InjectMock for replacing CDI beans in integration tests Dev Services for database/Kafka/Redis — avoid manual Testcontainers setup when Dev Services suffice @QuarkusTestResource for custom external service lifecycle Remember : Keep code intentional, typed, and observable. Optimize for maintainability over micro optimizations unless proven necessary.

java-coding-standards