kotlin-tooling-java-to-kotlin
Java to Kotlin Conversion
Convert Java source files to idiomatic Kotlin using a disciplined 4-step conversion methodology with 5 invariants checked at each step. Supports framework-aware conversion that handles annotation site targets, library idioms, and API preservation.
Workflow
digraph j2k_workflow {
rankdir=TB;
"User specifies files" -> "Step 0: Scan & Detect";
"Step 0: Scan & Detect" -> "Load framework guides";
"Load framework guides" -> "Step 1: Convert";
"Step 1: Convert" -> "Step 2: Write .kt";
"Step 2: Write .kt" -> "Step 3: Git rename";
"Step 3: Git rename" -> "Step 4: Verify";
"Step 4: Verify" -> "Next file?" [label="pass"];
"Step 4: Verify" -> "Fix issues" [label="fail"];
"Fix issues" -> "Step 1: Convert";
"Next file?" -> "Step 0: Scan & Detect" [label="batch: yes"];
"Next file?" -> "Done" [label="no more files"];
}
Step 0: Scan & Detect Frameworks
Before converting, scan the Java file's import statements to detect which frameworks are in use. Load ONLY the matching framework reference files to keep context focused.
Framework Detection Table
| Import prefix | Framework guide |
|---|---|
org.springframework.* |
SPRING.md |
lombok.* |
LOMBOK.md |
javax.persistence.*, jakarta.persistence.*, org.hibernate.* |
HIBERNATE.md |
com.fasterxml.jackson.* |
JACKSON.md |
io.micronaut.* |
MICRONAUT.md |
io.quarkus.*, javax.enterprise.*, jakarta.enterprise.* |
QUARKUS.md |
dagger.*, dagger.hilt.* |
DAGGER-HILT.md |
io.reactivex.*, rx.* |
RXJAVA.md |
org.junit.*, org.testng.* |
JUNIT.md |
com.google.inject.* |
GUICE.md |
retrofit2.*, okhttp3.* |
RETROFIT.md |
org.mockito.* |
MOCKITO.md |
If javax.inject.* is detected, check for Dagger/Hilt vs Guice by looking for other
imports from those frameworks. If ambiguous, load both guides.
Step 1: Convert
Apply the conversion methodology from CONVERSION-METHODOLOGY.md.
This is a 4-step chain-of-thought process:
- Faithful 1:1 translation — exact semantics preserved
- Nullability & mutability audit — val/var, nullable types
- Collection type conversion — Java mutable → Kotlin types
- Idiomatic transformations — properties, string templates, lambdas
Five invariants are checked after each step. If any invariant is violated, revert to the previous step and redo.
Apply any loaded framework-specific guidance during step 4 (idiomatic transformations).
Step 2: Write Output
Write the converted Kotlin code to a .kt file with the same name as the original
Java file, in the same directory.
Step 3: Preserve Git History
To preserve git blame history, use a two-phase approach:
# Phase 1: Rename (creates rename tracking)
git mv src/main/java/com/example/Foo.java src/main/kotlin/com/example/Foo.kt
git commit -m "Rename Foo.java to Foo.kt"
# Phase 2: Replace content (tracked as modification, not new file)
# Write the converted Kotlin content to Foo.kt
git commit -m "Convert Foo from Java to Kotlin"
If the project keeps Java and Kotlin in the same source root (e.g., src/main/java/),
rename in place:
git mv src/main/java/com/example/Foo.java src/main/java/com/example/Foo.kt
If the project does not use Git, simply write the .kt file and delete the .java file.
Step 4: Verify
After conversion, verify using checklist.md:
- Attempt to compile the converted file
- Run existing tests
- Check annotation site targets
- Confirm no behavioral changes
Batch Conversion
When converting multiple files (a directory or package):
- List all
.javafiles in the target scope - Sort by dependency order — convert leaf dependencies first (files that don't import other files in the conversion set), then work up to files that depend on them
- Convert one file at a time — apply the full workflow (steps 0-4) for each
- Track progress — report which files are done, which remain
- Handle cross-references — after converting a file, update imports in other Java files if needed (e.g., if a class moved packages)
For large batches, consider converting in packages (bottom-up from leaf packages).
Common Pitfalls
See KNOWN-ISSUES.md for:
- Kotlin keyword conflicts (
when,in,is,object) - SAM conversion ambiguity
- Platform types from Java interop
@JvmStatic/@JvmField/@JvmOverloadsusage- Checked exceptions and
@Throws - Wildcard generics → Kotlin variance
More from jetbrains/skills
spring-kotlin-code-review
Review Kotlin + Spring changes for behavioral regressions, transaction and proxy bugs, API and serialization mistakes, persistence risks, security issues, configuration drift, and missing tests. Use when reviewing a PR, diff, patch, or design change where generic style-focused review would miss Spring-specific correctness and operational risks.
4dependency-conflict-resolver
Diagnose and resolve Gradle and Spring classpath conflicts, version drift, and binary incompatibilities in Kotlin applications. Use when `NoSuchMethodError`, `ClassNotFoundException`, linkage errors, duplicate logging bindings, Jackson or Hibernate mismatches, or BOM-versus-explicit-version conflicts appear, and the fix must respect the repository's real version authorities.
3doc
Use when the task involves reading, creating, or editing `.docx` documents, especially when formatting or layout fidelity matters; prefer `python-docx` plus the bundled `scripts/render_docx.py` for visual checks.
3kotlin-spring-proxy-compatibility
Diagnose and prevent Kotlin plus Spring proxy failures around `@Transactional`, `@Cacheable`, `@Async`, method security, retry, configuration proxies, and JPA entity requirements. Use when AOP annotations appear to do nothing, transactional or cache behavior is inconsistent, compiler plugins may be missing, self-invocation is suspected, or Kotlin final-by-default semantics may break Spring behavior.
3ci-cd-containerization-advisor
Design reproducible build, image, and deployment pipelines for Kotlin plus Spring applications, including CI verification, layered containers, rollout safety, and deployment-time migration coordination. Use when creating or improving Dockerfiles, CI workflows, image hardening, Kubernetes manifests, release gates, or deployment strategies for Spring Boot services, especially where build reproducibility and operational safety matter.
3kotlin-idiomatic-refactorer-spring-aware
Refactor Kotlin code toward clearer, more idiomatic design without breaking Spring behavior, serialization, persistence, or public contracts. Use when Java-flavored Kotlin needs cleanup, domain modeling should become more expressive, or boilerplate should be reduced, but the refactoring must remain safe for proxies, Jackson, JPA, configuration binding, and existing tests.
3