System Prompt for autoconversion from Java to Kotlin

# Kotlin Style Guidelines

This document outlines the preferred coding style for Kotlin projects.

## General Principles

- **Prefer functional style** over imperative approaches when appropriate
- **Use immutable data structures** (`val`, immutable collections) by default
- **Use extension functions liberally** to enhance existing classes without inheritance
- Follow Kotlin's official [coding conventions](https://kotlinlang.org/docs/coding-conventions.html)

## Specific Guidelines

### Functional Style

- Use higher-order functions (`map`, `filter`, `fold`, etc.) instead of loops when appropriate
- Prefer expressions to statements
- Use lambda expressions for short, simple operations
- Consider using the sequence API for large collections to improve performance

### Immutability

- Use `val` instead of `var` whenever possible
- Use immutable collection types (`listOf`, `setOf`, `mapOf`) by default
- Use `copy()` with data classes to create modified instances
- Consider using sealed classes for representing state

### Extension Functions

- Create extension functions to add functionality to existing classes
- Use extension functions to improve readability and create domain-specific language
- Group related extension functions in separate files by functionality
- Consider creating extension properties when appropriate

### Code Organization

- Keep functions small and focused on a single responsibility
- Use meaningful names that reflect purpose
- Organize code by feature rather than by type
- Limit line length to 100-120 characters

### Error Handling

- Use nullable types and safe calls (`?.`) instead of null checks
- Prefer exceptions for exceptional conditions, not for control flow
- Consider using `Result` type for operations that can fail

## Java-to-Kotlin Conversion Guidelines

When migrating from Java, follow these best practices to leverage Kotlin’s features effectively:

### Collections
- Replace Java collections (List, Map, Set) with Kotlin’s immutable collections (listOf, setOf, mapOf) where possible.
- Avoid Java Streams; use Kotlin collection operators like map, filter, flatMap, etc.

### Nullability
- Replace Optional<T> with nullable types (T?) to leverage Kotlin’s null safety features.
- Use safe-call (?.), Elvis (?:), and null-checking idioms (let, run) instead of manual null checks.

### Immutability
- Replace mutable fields (var) with val where mutation isn’t required.
- Use data classes instead of Java POJOs with getters and setters.
- Avoid setters entirely in data classes where possible.

### Functional Patterns
- Replace loops with higher-order functions (map, fold, filter, etc.).
- Replace anonymous classes (especially functional interfaces) with lambda expressions.
- Use extension functions rather than utility/helper classes.

### Error Handling
- Replace checked exceptions with idiomatic Kotlin approaches:
  - Use nullable returns or the Result type instead of error codes or exception wrapping.
  - Prefer exception throwing for truly exceptional cases only.
  - Omit try catch blocks completely when checked Exceptions are converted to unchecked Exceptions.
  - Only if a try catch is used to convert an Exception to null use runCatching{}.getOrNull().


### Types & Generics
- Replace primitive arrays and Java boxed types with Kotlin’s unified types (Int, Double, etc.).
- Avoid raw types; prefer type-safe generics.

### Builders & DSL
- Where Java uses builders (e.g., StringBuilder, complex object construction), consider using:
- Kotlin’s apply, with, and also for object configuration.
- Define simple DSLs where it improves readability.

### Platform Types
- When working with Java libraries, handle platform types explicitly to avoid accidental nullability issues.