Hey everyone!

I wanted to share a library I recently built to reduce boilerplate when writing tests.

I was getting really tired of hand-crafting massive dummy objects, breaking test isolation with shared instances, and having dozens of tests fail to compile just because I added a single field to a data class. I used tools like kotlinfixture and Kotest Arbs for a while, but I wanted something that was 100% pure Kotlin under the hood to perfectly handle things like Sealed Interfaces.

So, I built Some. It’s a Kotlin JVM library that instantly generates fully populated test instances without any setup. You just call:

val testObject = some<MyClass>()

...and it handles the rest (including deeply nested structures and recursive sealed classes).

I just published it on GitHub and also blog post about why I built it and how it works. I'd love for you to check it out and hear any feedback!

💻 GitHub: https://github.com/MessiasLima/Some
📖 Docs: https://some.appoutlet.dev/
📣 Blog post:  https://blog.appoutlet.dev/some-a-library-to-generate-dummy-objects-for-unit-testing-in-kotlin/

Guys I am newbee , i have done DSA in Java , i have intermediate knowledge of web dev , know during my summer break I am thinking to learn android development and for that I wish to start with Kotlin, please if someone is experienced can u suggest me a beginner Friendly course with a good tutor .. i was thinking to go for chai aur code - mobile dev but I didn't find that on tg 🫠, please suggest me a good course x😭🥺

Hi r/Kotlin,

I’ve been working on a small finite-state-machine library for the JVM:

https://github.com/NGirchev/fsm

The original goal was simple: I often have domain objects with a `status` / `state` field, and I want transitions to be explicit instead of scattered across services as `if/when` blocks.

The library supports:

- Kotlin-first FSM builder API

- domain FSMs that apply transitions to an existing object

- guards / conditional transitions

- actions and timeouts

- Mermaid and PlantUML diagram generation

- Java usage as well, since it is a JVM library

Recently I also tried an experiment: I built a visual FSM editor for this library almost as a one-shot implementation using Codex CLI with GPT-5.5. I only tested it lightly so far, but code generation already works for both Kotlin and Java.

I’m curious whether this direction feels useful to Kotlin/JVM developers, or whether you’d rather keep FSM definitions purely in code.

https://i.redd.it/1nuyld9tgq1h1.gif

Хочу написать Java бот в телеграм который превращает видео в гифку 512 на 512 и тд

Chat gpt для подсказки можно использовать

Пока что самый лучший Gpt чат

Хочу написать Java бот в телеграм который превращает видео в гифку 512 на 512 и тд

Для телеграмма бота

Сайт пока что создавать не хочу так как содержание норм домена затратно

I currently have 3 completely separate IntelliJ projects: Kotlin project, Dart Project and React/TypeScript project. All 3 projects sit inside of a sinlge git repo:

Git Root

Kotlin Project

• Kotlin module 1
• Kotlin module 2
• Kotlin module 3

Dart Project

• Dart module 1
• Dart module 2
• Dart module 3

React/Typescript Project

I was thinking of combining them into one large IntelliJ project, that sits at the git root.

I was wondering how others organize a project like this?

The industry is currently burning billions on server GPUs, and the trend of moving computations to the Edge (end devices) has already started. Apple Intelligence and local NPUs in Android flagships are just the beginning.

Privacy by Design: For projects involving personal data, privacy is critical. Running everything through server cloud systems is a cost of today's technologies, while doing it through local LLMs and MAS is a killer feature. The data does not leave the device!

Native Concurrency: Python suffers from the GIL and workarounds in asynchrony. In KMP, we get native Coroutines and Flow. Agents in Koog are simply lightweight coroutines that communicate via channels without blocking the app's UI thread. This is elegant and mathematically rigorous.

KMP + Koog is the ideal foundation for Client-Side MAS. Python dominates in AI only because of its historically established ecosystem of mathematical libraries. But for orchestrating agents on the device, it is terrible.

But at the moment, we are hostages to the current stage of technological development and popular trends(

jir

Language: English | 中文

jir helps you manage Java versions without fighting JAVA_HOME.

Install a JDK, switch to it, and keep your active Java runtime behind one stable path: home/occupy.

Why

If you often switch between Java 8, 17, 21, or different vendors like Temurin, Corretto, Zulu, Oracle, and Microsoft OpenJDK, jir keeps that workflow simple.

You can set JAVA_HOME to home/occupy once. After that, jir use 21:temurin switches Java without editing environment variables again.

On Windows, switching uses a directory junction, so it is fast and does not copy the whole JDK.

Install

Download or build the Windows GUI installer:

dist/jir-0.1.0-windows-x64-gui-setup.exe

The installer lets you choose where jir lives. It can also add jir to PATH and set JAVA_HOME for you.

After installing, open a new terminal and check:

jir -h

Quick Start

See what you can install:

jir ls -i

Install Java 21. If there are multiple vendors, jir will let you choose one:

jir i 21

Already know what you want?

jir i 21:temurin

Switch to it:

jir use 21:temurin

Check what is active:

jir current

Remove something you no longer need:

jir uni 21:temurin

Commands

• jir, jir -h, jir -help, jir --help: show help.
• jir ls: show installed JDKs.
• jir ls -i: show installable JDKs.
• jir i 21: install Java 21 and choose a vendor.
• jir i 21:temurin: install a specific distro.
• jir use 21: choose an installed Java 21 distro and activate it.
• jir use 21:temurin: activate a specific installed distro.
• jir current: show the active Java runtime.
• jir uni 21:temurin: uninstall a JDK after confirmation.

About 5 months ago, I shared a technical experiment here. I was building an isometric RPG called Adventurers Guild using Pure Kotlin and Jetpack Compose instead of a traditional game engine. Back then, I was testing a custom coroutine loop and viewport culling to hold 60fps with 3000 entities on a Canvas.

Since that post, the game has crossed 4000 downloads. This custom Kotlin engine was recently shortlisted for the JetBrains Golden Kodee Community Award for Creativity. While I did not make it to the final round, getting that recognition from the Kotlin community as a solo developer was a significant milestone.

Writing a game engine natively in Kotlin means you have to fiercely protect the frame budget and minimize Garbage Collection pauses. I wanted to share the technical solutions I used to keep the Kotlin game loop smooth while scaling the simulation to handle a massive item database and complex AI.

1. The Coroutine Game Loop and Task Amortization The engine is single threaded and driven by a Coroutine loop using withFrameMillis to calculate delta time. The engine currently ticks over 28 distinct systems, handling everything from A Star Pathfinding to the Combat Pipeline.

Running 28 systems over thousands of entities every single frame is a recipe for GC churn and frame drops. To fix this, I implemented a tiered System Manager. Logic is categorized by its necessity for visual fluidity:

• Fast Systems (60 FPS): Essential movement and frame by frame Canvas rendering.
• Medium Systems (30 FPS): Combat calculations, damage application, and status effect updates.
• Slow Systems (10 FPS): Heavy background tasks like A Star pathfinding and target selection AI.

Slicing these tasks over different frames prevents the Kotlin logic calculations from blocking the Compose composition phase.

2. Idiomatic ECS and State Mapping Managing game state in Compose requires bridging raw ECS data to stable UI states. Entities are simple IDs, and Components are raw Kotlin data classes. The systems iterate over these components to mutate state. Connecting this high frequency ECS to the Compose UI relies on a Mapper pattern. Every frame, the engine maps the relevant raw Components into a stable UiModel. Relying on MutableMap for O(1) time complexity lookups has been critical to prevent the main thread from choking when updating multiple entities at once.

3. The Optimization Triangle: CPU vs RAM vs GPU The biggest lesson over the last 5 months was managing the trade offs between hardware resources:

• Trading RAM for GPU Processing: I added 40 new monster variants. To avoid loading 40 unique sprite sheets, I used Compose ColorFilter techniques. For monsters with high detail, I load a single base asset and mathematically rotate the hue using a ColorMatrix at runtime. Because these operations are hardware accelerated, the math is offloaded to the GPU. This cut RAM usage by 50 percent while keeping the CPU free.
• Trading CPU for RAM (Caching): Dynamic shadows change angle and length based on the in game time. Instead of calculating this geometry every frame, the engine pre calculates the shadow states for the day and caches them. I spend a small amount of RAM to buy back crucial CPU frame time.

4. Micro Optimizations in the Hot Path When writing systems that execute thousands of times a second in Kotlin, you have to respect CPU clock cycles. I learned that operations like addition and multiplication are significantly faster for a CPU to process than division or calculating square roots. To optimize the hot path, I removed division where possible, opting to multiply by fractions instead. I also rely strictly on squared distance comparisons to avoid expensive square root calculations in the pathfinding logic.

5. Expanding the RPG Logic The simulation has scaled heavily since the initial experiment:

• Hero Classes: Heroes have specific classes that alter their base stats, scaling performance based on equipped gear.
• Personality AI: Heroes carry flags that alter their ECS logic. Careful heroes query the health of teammates and prioritize support over loot, while Reckless heroes ignore teammate health and stay in a combat state until the mob is cleared.

Building this engine and expanding the game from scratch has been a massive learning experience. Seeing the performance hold up on older devices makes the effort worth it.

I am happy to answer any questions about writing game loops with Coroutines, managing ECS state in Compose, or the DrawScope art workflow.

If you are curious to see how this custom Kotlin engine handles these 28 systems in production, you can check it out on the Play Store: Adventurers Guild

I am a solo dev from Kerala. Hope this technical breakdown was helpful.

        <dependency>
            <groupId>org.jetbrains.kotlinx</groupId>
            <artifactId>kotlinx-coroutines-core</artifactId>
            <version>1.11.0</version>
        </dependency>

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.coroutineScope
import kotlinx.coroutines.launch
import kotlinx.coroutines.withContext
import java.io.File
import kotlin.time.Duration.Companion.milliseconds


suspend fun createFile(idx: Int) {
    val filename = "/Users/myousuf/dev/test/testfiles/file$idx.txt"
    val file = File(filename)
    withContext(Dispatchers.IO) {
        file.createNewFile()
    }
    file.writeText("hello world how are you my name is test")
}

suspend fun deleteFile(idx: Int) {
    val filename = "/Users/myousuf/dev/test/testfiles/file$idx.txt"
    val file = File(filename)
    withContext(Dispatchers.IO){
        file.delete()
    }
}

suspend fun main() {

    val startDelete = System.currentTimeMillis()
    println("starting delete operation now")
    coroutineScope {
        List(300_000) { idx ->
            launch(Dispatchers.IO) {
                deleteFile(idx)
            }
        }
    }
    val endDelete = System.currentTimeMillis();
    val diffDelete = endDelete - startDelete
    println("Delete operation took: ${diffDelete.milliseconds.inWholeSeconds} seconds")


    val dir = File("/Users/myousuf/dev/test/testfiles")
    println(dir.listFiles()?.forEach { println(it.name)})

    println("starting file creation now")
    val starttime = System.currentTimeMillis()
    coroutineScope {
        List(300_000) { idx ->
            launch(Dispatchers.IO) {
                createFile(idx)
            }
        }
    }
    val endtime = System.currentTimeMillis()
    val diff = endtime - starttime
    println("time taken for file creation: ${diff.milliseconds.inWholeSeconds} seconds")

}

So this is my code, and the following is the output of this code.

starting delete operation now
Delete operation took: 15 seconds
kotlin.Unit
starting file creation now
time taken for file creation: 18 seconds

Can anyone explain to me why it's taking 15 seconds? I mean, why can it not fire all these 300_000 lightweight coroutines at the same time, which will perform the create and delete operations in parallel so that everything is completed in like five seconds?

Quick heads-up for the Spring Boot crowd: JobRunr 8.6.0 just shipped and the Spring Boot starter (both 3.x and 4.x) now boots the Background Job Server and Dashboard on ApplicationReadyEvent instead of SmartInitializingSingleton.afterSingletonsInstantiated(). That means JobRunr only starts polling once your application context is fully initialized, which avoids a whole class of subtle startup races where a job ran before its dependencies were ready.

Also in this release:

• JDK 26 compatibility (works with --illegal-final-field-mutation=deny)
• Quarkus 3.33 LTS support (yes, also relevant if you run a hybrid stack)
• 40+ minute → 5 second startup on databases with thousands of tables
• Recurring job lookup uses a single MAX query, throughput back to historical levels
• withDetails → withJobLambda rename for the Fluent API (old name deprecated, still works)
• Job logs in the dashboard preserve whitespace now

Release blogpost with code-examples: https://www.jobrunr.io/en/blog/jobrunr-v8.6.0/