Kotlin Tooling Java To Kotlin
JetBrainsOfficialCreated by JetBrainsDistributed by JetBrains
- Skill
- Workflow
- Software development
- Apache-2.0
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a disciplined, four-step methodology for migrating Java code to Kotlin. It includes framework-aware guidance for common JVM libraries such as Spring, Hibernate, Lombok, and others. The process emphasizes maintaining behavioral parity through a chain-of-thought approach, checking five specific invariants at each stage to ensure the resulting Kotlin code is idiomatic, safe, and maintainable.
What it does
- Scans Java files to detect and load relevant framework-specific conversion guides.
- Executes a four-step conversion process: 1:1 translation, nullability audit, collection conversion, and idiomatic transformation.
- Validates code against five core invariants at every step to prevent regressions.
- Provides instructions for preserving Git history during file renaming.
- Offers a checklist for verifying compilation and behavioral consistency.
- Handles common pitfalls like keyword conflicts, SAM ambiguity, and platform types.
When to use it
- When migrating existing Java projects or individual files to Kotlin.
- When you need to ensure converted code follows idiomatic Kotlin patterns.
- When working with Java codebases that utilize frameworks like Spring, Hibernate, or Dagger.
- When you need to maintain Git blame history while refactoring Java to Kotlin.
Advantages
- Reduces manual effort by providing a systematic, repeatable conversion workflow.
- Ensures framework-specific idioms are applied correctly through targeted reference guides.
- Maintains code integrity by enforcing strict invariants throughout the transformation.
- Minimizes common interop issues by addressing platform types and JVM annotations.
Usage examples
- “Convert this Java file to idiomatic Kotlin.”
- The agent will scan the file for frameworks, perform the four-step conversion, and output the resulting .kt file.
- “Migrate my Java project to Kotlin.”
- The agent will list all .java files, sort them by dependency order, and perform a batch conversion following the defined workflow.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/jetbrains/kotlin-tooling-java-to-kotlin/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip kotlin-tooling-java-to-kotlin.zip -d .agents/skills
Documentation by JetBrains
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.ktIf 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 scopeSort 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/@JvmOverloadsusageChecked exceptions and
@ThrowsWildcard generics → Kotlin variance
Files
- ATTRIBUTION.mdAdded by AutoGineer1023 B
- LICENSEAdded by AutoGineer10.0 KiB
- SKILL.md5.6 KiB
- assets/checklist.md2.5 KiB
- references/CONVERSION-METHODOLOGY.md9.8 KiB
- references/KNOWN-ISSUES.md9.5 KiB
- references/frameworks/DAGGER-HILT.md4.3 KiB
- references/frameworks/GUICE.md4.5 KiB
- references/frameworks/HIBERNATE.md5.9 KiB
- references/frameworks/JACKSON.md7.1 KiB
- references/frameworks/JUNIT.md5.3 KiB
- references/frameworks/LOMBOK.md6.3 KiB
- references/frameworks/MICRONAUT.md3.3 KiB
- references/frameworks/MOCKITO.md7.7 KiB
- references/frameworks/QUARKUS.md3.8 KiB
- references/frameworks/RETROFIT.md4.4 KiB
- references/frameworks/RXJAVA.md5.6 KiB
- references/frameworks/SPRING.md6.3 KiB
references/KNOWN-ISSUES.md
Known Issues and Common Pitfalls
A reference of common issues encountered during Java-to-Kotlin conversion, with solutions.
Kotlin Keyword Conflicts
Java identifiers that are reserved keywords in Kotlin will cause compilation errors after conversion.
Affected keywords: when, in, is, object, fun, val, var, typealias, as
Solution: Backtick-escape them in Kotlin:
// Java
public void when(String event) { ... }
public boolean in(List<String> items) { ... }// Kotlin — backtick-escaped
fun `when`(event: String) { ... }
fun `in`(items: List<String>): Boolean { ... }When the API is internal (not exposed to other modules), prefer renaming the identifier to a non-keyword alternative instead of using backticks. For example, rename when to onEvent or in to contains.
SAM Conversion Ambiguity
When a Java method has overloads that each accept a different SAM (Single Abstract Method) interface, Kotlin's trailing lambda syntax becomes ambiguous. The compiler cannot determine which SAM interface the lambda should implement.
// Java — overloaded method accepting different SAM types
public class TaskExecutor {
void submit(Runnable task) { ... }
void submit(Callable<String> task) { ... }
}// Kotlin — WRONG: ambiguous, won't compile
executor.submit { doWork() }
// Kotlin — CORRECT: explicit SAM constructor
executor.submit(Runnable { doWork() })
executor.submit(Callable { computeResult() })Use explicit SAM constructor calls whenever there are overloaded methods accepting different functional interfaces.
Platform Types
Java types without nullability annotations (@Nullable, @NotNull, @NonNull) become "platform types" (T!) in Kotlin. Platform types bypass Kotlin's null-safety system — they are neither nullable nor non-null, and null checks are deferred to runtime.
// Java — no nullability annotations
public String getName() { return name; }
public List<String> getItems() { return items; }// Kotlin — BAD: platform types left in converted code
val name = obj.name // inferred as String! — unsafe
val items = obj.items // inferred as List<String!>! — unsafe
// Kotlin — GOOD: explicit nullability based on code analysis
val name: String = obj.name // if provably non-null
val name: String? = obj.name // if could be null
val items: List<String> = obj.items // if neither list nor elements are nullAlways add explicit type declarations to eliminate platform types. Analyze the Java source code, documentation, and call sites to determine the correct nullability.
@JvmStatic / @JvmField / @JvmOverloads
When converted Kotlin code is still called from Java, use JVM interop annotations to maintain a clean Java API:
@JvmStatic — Makes companion object functions accessible as static methods from Java:
class Config {
companion object {
@JvmStatic
fun getInstance(): Config = ...
}
}// Java callers can use: Config.getInstance()
// Without @JvmStatic they would need: Config.Companion.getInstance()@JvmField — Exposes a property as a direct field rather than through getter/setter:
class Constants {
companion object {
@JvmField
val DEFAULT_TIMEOUT = 30_000L
}
}// Java callers can use: Constants.DEFAULT_TIMEOUT
// Without @JvmField they would need: Constants.Companion.getDEFAULT_TIMEOUT()@JvmOverloads — Generates Java overloads for functions with default parameters:
@JvmOverloads
fun connect(host: String, port: Int = 443, secure: Boolean = true) { ... }// Java sees three overloads:
// connect(String host)
// connect(String host, int port)
// connect(String host, int port, boolean secure)Checked Exceptions
Kotlin does not have checked exceptions. When Kotlin code is called from Java, the Java compiler will not know about thrown exceptions unless annotated with @Throws:
// Without @Throws, Java callers cannot catch IOException in a catch block
// (the Java compiler will say "exception is never thrown in the corresponding try block")
@Throws(IOException::class)
fun readFile(path: String): String {
return File(path).readText()
}Add @Throws to every Kotlin function that throws checked exceptions and is called from Java code.
Wildcard Generics
Java wildcard types map to Kotlin's variance annotations:
| Java | Kotlin | Description |
|---|---|---|
? extends T | out T | Covariance (producer) |
? super T | in T | Contravariance (consumer) |
Raw type List | List<Any?> | Add explicit type parameter |
// Java
public void process(List<? extends Number> numbers) { ... }
public void addAll(List<? super Integer> target) { ... }
public void legacy(List items) { ... } // raw type// Kotlin
fun process(numbers: List<out Number>) { ... }
fun addAll(target: MutableList<in Int>) { ... }
fun legacy(items: List<Any?>) { ... } // explicit type parameterFor raw types, analyze the code to determine the most specific type parameter rather than defaulting to Any?.
Static Members
Java's static keyword has no direct equivalent in Kotlin. Use the following mappings:
Static methods — Use companion object functions, or top-level functions if they don't need class state:
// Java
public class StringUtils {
public static String capitalize(String s) { ... }
}// Kotlin — top-level function (preferred when no class state needed)
fun capitalize(s: String): String { ... }
// Kotlin — companion object (when logically tied to the class)
class StringUtils {
companion object {
fun capitalize(s: String): String { ... }
}
}Static constants — Use const val for compile-time constants (primitives and String), val for object constants:
class HttpStatus {
companion object {
const val OK = 200 // primitive — const val
const val NOT_FOUND_MESSAGE = "Not Found" // String — const val
val DEFAULT_HEADERS = mapOf("Accept" to "application/json") // object — val
}
}Static initializers — Use companion object init {} block or top-level code:
class Registry {
companion object {
private val handlers = mutableMapOf<String, Handler>()
init {
handlers["default"] = DefaultHandler()
}
}
}Synchronized Blocks
Java's synchronized constructs map to Kotlin as follows:
Synchronized blocks — Use Kotlin's synchronized() function:
// Java
synchronized (lock) {
sharedState.update();
}// Kotlin
synchronized(lock) {
sharedState.update()
}Synchronized methods — Use the @Synchronized annotation:
// Java
public synchronized void update() { ... }// Kotlin
@Synchronized
fun update() { ... }Anonymous Inner Classes
Single Abstract Method (SAM) interfaces — Convert to lambda syntax:
// Java
executor.submit(new Runnable() {
@Override
public void run() {
doWork();
}
});// Kotlin
executor.submit(Runnable { doWork() })Multiple methods or abstract classes — Use object expression:
// Java
view.addListener(new ViewListener() {
@Override
public void onOpen() { ... }
@Override
public void onClose() { ... }
});// Kotlin
view.addListener(object : ViewListener {
override fun onOpen() { ... }
override fun onClose() { ... }
})Array Handling
Java arrays map to Kotlin types as follows:
| Java | Kotlin | Notes |
|---|---|---|
String[] | Array<String> | Reference type arrays |
int[] | IntArray | Primitive array (not Array<Int>) |
long[] | LongArray | Primitive array |
double[] | DoubleArray | Primitive array |
boolean[] | BooleanArray | Primitive array |
Object[] | Array<Any?> | |
new int[10] | IntArray(10) | Array creation |
new String[10] | arrayOfNulls<String>(10) | Nullable element array |
String... args | vararg args: String | Varargs parameter |
Using Array<Int> instead of IntArray causes boxing overhead — always use the specialized primitive array types.
Ternary Operator
Kotlin has no ternary operator. Use if/else as an expression:
// Java
String label = (count > 0) ? "Items: " + count : "Empty";// Kotlin
val label = if (count > 0) "Items: $count" else "Empty"instanceof
Java's instanceof maps to Kotlin's is keyword. Kotlin supports smart casting, so an explicit cast after an is check is unnecessary:
// Java
if (shape instanceof Circle) {
Circle circle = (Circle) shape;
double area = circle.getArea();
}// Kotlin — smart cast, no explicit cast needed
if (shape is Circle) {
val area = shape.area // shape is automatically cast to Circle
}try-with-resources
Java's try-with-resources maps to Kotlin's .use {} extension function:
// Java
try (BufferedReader reader = new BufferedReader(new FileReader(path))) {
String line = reader.readLine();
process(line);
}// Kotlin
BufferedReader(FileReader(path)).use { reader ->
val line = reader.readLine()
process(line)
}The .use {} function works on any Closeable or AutoCloseable instance and guarantees the resource is closed even if an exception is thrown.
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs a command-line tool
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- JetBrains
- Publisher
- JetBrains (Official)
- Distributed by
- JetBrains
- Source
- JetBrains/skills · kotlin-tooling-java-to-kotlin · commit 3f53782
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (written by AutoGineer)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by JetBrains or JetBrains.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download kotlin-tooling-java-to-kotlin.zip