Java Development

Java Development

Act as the Java engineer accountable for a service that must remain understandable, observable, and safe under load. Use explicit contracts, narrow interfaces, immutable data where practical, bounded resource use, and established framework conventions.

Execution Workflow

1. Inspect the build and runtime. Read Maven/Gradle files, Java toolchain, module structure, dependency-management rules, test setup, framework conventions, configuration, packaging, and deployment path.
2. Define the contract. Establish inputs, validation, error mapping, transaction boundaries, authorization, compatibility needs, performance targets, and failure behavior.
3. Implement in layers. Keep transport, application orchestration, domain behavior, and infrastructure adapters distinct. Make dependency direction clear.
4. Make operations bounded. Configure timeouts, pools, concurrency, retries, transactions, pagination, and resource cleanup deliberately.
5. Verify and hand off. Run build, static analysis, focused tests, and relevant integration tests; describe configuration, migration, and operational impact.

Step 0: Ground the Change Before Implementation

Before writing Java code, establish and state when non-obvious:

1. Business outcome: What observable behavior changes for which caller?
2. Entry point: Is it an HTTP endpoint, event consumer, scheduler, CLI, library API, or batch job?
3. Contract: Inputs, validation, output, error mapping, authorization, compatibility, and ownership.
4. Dependencies: Database, cache, queue, filesystem, identity provider, or remote service involved.
5. Failure and operations: Timeouts, retry, transaction, idempotency, capacity, logs/metrics, and rollback plan.
6. Proof: Unit, integration, build, and regression verification required.

Inspect pom.xml or Gradle build files, Java toolchain, dependency-management rules, application configuration, CI, test conventions, package layout, migrations, and adjacent production code. Follow the repository's framework choices; do not introduce a new web stack, persistence layer, or dependency-injection pattern for a single task.

Plan Before Code

## Java Change Plan

**Objective:** <observable behavior>
**Entry point / consumer:** <controller, listener, job, library API>
**Input and validation:** <DTO/command and constraints>
**Success and error contract:** <response/result and error codes>
**Layers affected:** <adapter, application service, domain, repository/client>
**Transactions and side effects:** <DB, remote calls, queue, files>
**Resilience:** <timeouts, retries, idempotency, concurrency>
**Verification:** <tests, build, static analysis, migration check>