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]:
@Singletonwhere@ApplicationScopedis intended — breaks proxying and interception - [QUARKUS]: Mixing
quarkus-resteasy-reactiveandquarkus-resteasy(classic) — pick one stack - [QUARKUS]: Panache active-record + repository pattern in the same bounded context — pick one
Logging
Null Handling
- Accept
@Nullableonly when unavoidable; otherwise use@NonNull - Use Bean Validation (
@NotNull,@NotBlank) on inputs - [QUARKUS]: Apply
@Validon@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]
@WebMvcTestfor controller slices,@DataJpaTestfor repository slices@SpringBootTestreserved for full integration tests@MockBeanfor replacing beans in Spring context
[QUARKUS]
- Plain JUnit 5 + Mockito for unit tests (no
@QuarkusTest) @QuarkusTestreserved for CDI integration tests@InjectMockfor replacing CDI beans in integration tests- Dev Services for database/Kafka/Redis — avoid manual Testcontainers setup when Dev Services suffice
@QuarkusTestResourcefor custom external service lifecycle
Remember: Keep code intentional, typed, and observable. Optimize for maintainability over micro-optimizations unless proven necessary.

