# Writing Java Kotlin

> Idiomatic modern Java and Kotlin JVM development. Use when writing `.java`, `.kt`, or `.kts` code; changing Gradle or Maven builds; or working on Spring, Micronaut, Quarkus, Ktor, Android JVM modules, JUnit, Mockito, Kotest, ktlint, detekt, or JVM CLI/services. Emphasizes JDK toolchains, null-safety, fast focused Gradle/Maven feedback, deterministic formatting, and minimal dependencies. NOT for JavaScript/TypeScript, C#/.NET, Python, shell scripts, or infra-only work.

- Skill: `alexei-led/writing-java-kotlin` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add alexei-led/writing-java-kotlin`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alexei-led/writing-java-kotlin/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: alexei-led (https://skillmd.com/u/alexei-led)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/alexei-led/writing-java-kotlin

---


# Java and Kotlin Development

Use only for Java/Kotlin JVM code and JVM build files. Follow the project's JDK,
Kotlin, Gradle/Maven, framework, test stack, formatter, static-analysis config,
and local conventions.

## Read First

Read [principles.md](references/principles.md) before writing, changing, or reviewing Java/Kotlin code. Read conditional references only when the change touches that area.

## Conditional References

- [patterns.md](references/patterns.md) — package/module layout, Spring/Ktor/service boundaries, nullability, concurrency, persistence, and build seams.
- [testing.md](references/testing.md) — adding or reshaping JUnit, Kotest, Mockito/MockK, Spring, or Gradle/Maven tests; keep the local loop fast.
- [linting.md](references/linting.md) — Gradle/Maven toolchains, formatters, ktlint, detekt, Spotless, and slow-check policy.
- [cli.md](references/cli.md) — writing or changing JVM CLIs.

## Project Baseline

- Inspect `gradle/wrapper/gradle-wrapper.properties`, `settings.gradle*`, `build.gradle*`, `pom.xml`, `.mvn/`, `gradle.properties`, CI, and nearby code before using version-specific Java, Kotlin, or plugin behavior.
- Prefer the project wrapper: `./gradlew` before global `gradle`; `./mvnw` before global `mvn`.
- Use the configured Java toolchain and Kotlin `jvmToolchain`. Do not assume the shell's newest JDK is the compile target.
- Prefer the JDK/Kotlin stdlib and existing dependencies before adding a library.
- Keep domain code free of framework, persistence, HTTP, and DI types unless the project already chose that coupling.

## Version-Gated APIs

- Java 21+: records, sealed types, pattern matching, switch expressions, and virtual threads are available when the project toolchain allows them.
- Java 25+: treat new platform APIs as available only when Gradle/Maven toolchains and CI target 25 or newer.
- Preview features require explicit user or project approval and a visible compiler/test flag.
- Kotlin: follow the configured Kotlin language/API version. Do not use a Kotlin 2.x feature unless the build already enables it.

## Comments, Javadoc, and KDoc

- Use Javadoc or KDoc for visible public APIs when the project expects generated docs.
- Keep API docs to a useful summary, contract, edge case, or effect. Do not restate names and signatures.
- Omit comments for simple obvious getters, overrides, and data holders when there is nothing useful to add.
- Add implementation comments only for non-obvious constraints, invariants, side effects, tradeoffs, or framework quirks.
- Keep comments short. Move longer rationale to docs, issue links, or design notes.
- Do not comment obvious code.
- Keep tests readable without comments; add one only for unobvious fixtures, timing, concurrency, framework setup, or regression context.

## Verification

Run focused module tests and format/lint while editing, then the project-configured build, tests, lint, static analysis, and formatting checks before final output. Prefer Gradle/Maven test filtering over full-suite runs in the hot loop.

If a check is unavailable, state that and run the closest configured gate. If a
check fails, quote the failure, diagnose the cause, fix one issue, and rerun the
relevant check.

## Failure Cases

- No clear JVM root: locate the nearest `settings.gradle*`, `build.gradle*`, or `pom.xml` before choosing commands or package names.
- Unknown JDK or Kotlin target: inspect toolchains, compiler options, CI, and wrapper versions before using newer APIs or syntax.
- New dependency requested: confirm the JDK/Kotlin stdlib or existing dependencies cannot meet the requirement.
- Slow checks by default: switch to focused Gradle/Maven filters or file-scoped format/lint; reserve broad checks for final verification.
- Broad or risky edit: state the risk and ask before acting. Do not run destructive commands.

## Final Response

Include:

- changed files
- checks run and results
- checks skipped with reasons
- remaining risks or follow-ups