Hey guys I am building an app after trying few apps on those category, that is a bookmark manager app, literally they asked money to save some links, wtf!? Tried another app that was cool, but features like import export was paid! So i started building my own, with simple,clean UI.. and i recently released its public version on github.. i would love to hear some feedback from you!! Btw its for android only!

​

​

​

​

With RC1, the 1.0 API is now locked. The remaining work is testing it in real projects, fixing issues, and preparing the final release. 📋 Release notes: https://github.com/Kotlin/dataframe/releases/tag/1.0.0-rc01

For users, the practical takeaway is simple: if you have been waiting to update an existing project—or start a new one without targeting another Beta API—this is the version to try.

🧩 More typed DataFrame workflows in Gradle and Maven

The Compiler Plugin now understands more schema-changing transformations and edge cases. As a pipeline changes, it can keep typed column access available across more steps, with completion, refactoring, and compile-time checks in the IDE. Kotlin 2.4 also restores incremental compilation.

This brings more of the typed column experience familiar from notebooks to regular Kotlin projects.

A few useful additions:
🔎 requireColumn() helps connect dynamically loaded data with typed column access.
📄 renderToMarkdown() produces Markdown for reports, documentation, README files, issues, and pull requests.
📊 GroupBy.countDistinct() provides distinct counts for each group without extra boilerplate.
🧹 rename { ... }.to() makes the rename API easier to read, while DataFrame.print() now shows more useful table information by default.

RC1 also includes updates to SQL validation, JSON and IO configuration, DuckDB support, examples, and documentation.

Please try the release in a Gradle, Maven, or notebook workflow and share what you find before 1.0.

We are experimenting with a KSP-based approach to Kotlin validation where validation logic is generated during compilation and then executed at runtime.

But we wonder what their view is on this matter:

• What do you see as the biggest advantages of generated validation compared with reflection-based approaches?
• Where do you think the added KSP/build-time complexity becomes a disadvantage?
• What would you expect from a production-ready Kotlin validation library?

We are mainly interested in the technical discussion and criticism.

Repository: https://github.com/DeveloperSyndicate/Valix

The GraalVM Native Image build of the Kotlin compiler is available since 2.4.20-RC (see news). Has anyone tried it yet?

Also posting this for awareness, since I haven't read about it in many places outside of Slack.

I've spent the last ~6 months working on a fork of fwcd/kotlin-language-server, and I think it's finally at a point where it's worth showing to the broader Kotlin community.

The original kotlin-language-server is deprecated and has accumulated a number of performance, memory, and reliability issues, while JetBrains' official kotlin-lsp is still in alpha. The official repo also currently says that direct code contributions aren't supported because it is a read-only mirror.

The current situation left me with a fair question: what can I actually use if I want a good, fully open-source Kotlin LSP in an LSP-compatible editor today?

There are now different open-source Kotlin LSP implementations, including recent tree-sitter-based implementations that don't use the Kotlin compiler. Their approach is really interesting, especially if things like memory footprint are important to you. These kinds of LSPs provide useful syntactic and structural information, while not having access to the same deep semantic information that comes from the Kotlin compiler.

I wanted an LSP which uses the Kotlin compiler to provide more code information, while being a bit faster and more responsive.

So I started working on the existing language server instead of waiting for the situation to slowly improve, and after roughly 24 weeks and ~200 commits, ktlsp 1.4.0-RC1 is now available.

This is a bit more than a fork with a few patches

A lot has changed since the original 1.3.13 release, even if it's a minor version bump rather than a major version bump. Some of the bigger changes include:

• Much better navigation - go-to-definition, references, implementations, type definitions, call hierarchy and type hierarchy
• Cross-file rename support, including proper rename preparation/range validation and implicit it
• Much richer hover information, including KDoc/Javadoc from dependency JARs and the JDK
• Proper Markdown rendering for Javadoc, including @param, @return, {@code}, and code blocks
• Code lenses
• Java getter/setter pairs being exposed as Kotlin properties during completion
• Configurable filtering of noisy packages from completion results (like java.awt.*)
• Parser errors now appearing as diagnostics
• Fixed stale diagnostics and races that could cause diagnostics to disappear
• Compiler crashes being reported as diagnostics instead of silently failing
• Better Gradle classpath resolution through the Gradle Tooling API
• Better Maven dependency resolution
• Test dependencies being included correctly
• Automatic discovery of JDK src.zip
• Content-hashed classpath caches to avoid stale project state and faster startup
• Several memory leaks fixed by bounding internal caches
• A number of indexing, concurrency, database, and path-handling bugs fixed

There were also substantial dependency and infrastructure upgrades alongside all these changes. The embedded Kotlin version is now 2.2.21, the minimum JVM is Java 21, and the server can run on Java 25 (personally tested this).

ktlsp also supports Kotlin 2.3.0 projects, although I haven't tried any newer Kotlin version like 2.3.20 or 2.4.x.

The full release notes delve further into the changes I made, so please check them out at https://codeberg.org/winlogon/ktlsp/releases/tag/v1.4.0-rc1 so you can update your configuration accordingly.

Why release an RC and not a stable release?

I consider 1.4.0-RC1 to be essentially the version I want to release as 1.4.0, but at this point, what I'm much more interested in finding are the bugs that I haven't found.

An LSP is really difficult to test exhaustively. I've tested the server against different projects and environments myself, and I've spent a lot of time fixing cases where the Kotlin compiler's PSI/BindingContext contained useful information that the old implementation simply wasn't exposing through LSP.

That said, there are an enormous number of combinations of:

• Kotlin projects
• Gradle/Maven configurations
• OSes
• editors
• project structures
• generated sources
• dependencies
• and unusual Kotlin code

that I just can't test alone.

I actually found a couple of additional Windows-specific URI-related path conversion bugs while testing RC1 myself, which have already been fixed after the RC1 release.

This is exactly the type of bugs I'm hoping broader testing on multiple setups will bring to light.

So I'd really like people to try it

If you've previously tried kotlin-language-server and switched away from it because of bugs, memory usage, poor navigation, missing features, or general unreliability, I'd especially like to hear from you!

Please, try to break it as much as you can. Open your projects. Jump around. Find weird Javadoc quirks. Hover over dependency APIs. Try your weirdest Gradle setup. Use it from Neovim, VS Code, Emacs, Helix, or whatever editor you use.

And if something eventually breaks, please report it! It's even better if you can provide a reproducible project and/or a list of actions that causes the bug.

What about the official Kotlin LSP?

I'm not trying to argue that ktlsp is better than the official LSP for everyone. If it eventually becomes an excellent solution, that's great for Kotlin developers, and that changes where ktlsp stands...

... but right now it is still in alpha, and direct code contributions to that repository aren't currently supported.

ktlsp gives me a place where I can actually fix problems, experiment with the implementation, accept contributions, and ship those bugfixes in new versions.

What's next?

1.4.0 is primarily about making ktlsp substantially more reliable and useful. After that, I'd like to expand ktlsp's project support further.

My current goals for the next releases include Kotlin/Native and Android support, tentatively around the 1.5.x/1.6.x timeframe.

I'm also planning to switch from K1 to K2, which should open up opportunities for further performance improvements and support for newer Kotlin versions. I don't have an exact timeframe for this yet, though, as I'm not sure how effortful the transition will be.

That said, I want to get 1.4.0 properly finished first, but they're areas I'd like to work toward once 1.4.0 is out.

For the foreseeable future, this is where I'm continuing development of the fork. If you're happy with your current Kotlin setup, there's no reason to switch just because this LSP exists.

But if you've ever thought "Kotlin LSP support really shouldn't be this frustrating", I'd love for you to give 1.4.0-RC1 a shot.

Repository: https://codeberg.org/winlogon/ktlsp

Thanks for reading this post, and please break it.

Now with inference-based features!

I have spent the last 18 months building Konifer, an open source image management platform that links your image life cycle policy to the URL paths that match your application's domain. Store, transform, and deliver your image assets however you want!

I wanted to highlight some new features. Upload Rules allow you to define, using natural language, content policy rules. These are evaluated using Google's SigLip2 vision language model in-process to allow, reject, or modify images.

Using the Rule Evaluation allows you to run an image against prompt sets to test your Upload Rules. It can also be used as an image classifier API.

It's written using ktor, JOOQ and libvips. It has really helped me gain Kotlin development skills!

https://github.com/dmaiken/konifer/