Hey, I'd love to use Kotlin in a multi-module Open Source maven project. I've used it in one module exclusively. In other modules I'm currently using Java 13. Would you advise on using Kotlin and Java in a single module? I'd love to switch but don't want to rewrite everything. I haven't tried yet, but I guess the IntelliJ Java to Kotlin Converter for classes doesn't produce idiomatic Kotlin code, so I think it's better to just call the Java code from Kotlin and vice versa. Would you advise on mixing Java and Kotlin in a single module? Are there any pitfalls? Or should I have Java and Kotlin modules seperated from each other?

certain kotlin namespaces occupy the point of no return where java cannot see them. its easy to fix these by converting that java, but sometimes this has a domino effect. strangeness around enums and object and default interface methods can take some time to untangle. if you can decouple the kotlin you will have an easier time for sure.

HI @jimn These question interest me too. Could you expand a little bit your answer or just point to some documentation of that? I always had the idea that there should be no issue in mixing Kotlin+Java (even if I would avoid that for "clarity")

im porting a giant complex ai system from java and the conversion cornercases are too numerous to plainly list here in a short time. the biggest headaches are booleans using "isSomething" , methods using IsSomething(), getters with parameters, java default interface methods coexisting with abstract class overrides, and finding const attributes when converted from java.

👍 Thx! I had to port/split a big java monolith to kotlin microservices architecture, and had similir issue. Now It's clear what you are pointing at, thanks again!

Oh, I think I don't want to spend too much time. It's a smaller project (https://github.com/sirixdb/sirix) but I still don't want to spend too much time. I'll rather introduce a better API for Kotlin users I guess or even a DSL would be great. And I'll probably convert the query module, which is rather simple 🙂

wow i was just beginning my travels on time series resampling today!

Hi Jim, it's not exactly about time series, but to preserve lightweight snapshots of your data (that is store more or less only the changes plus some overhead as for instance some pages of a keyed persistent trie datastructure and neighbour nodes). However, performance should not be hurt and predictable (sliding window algorithm to version data pages) and it doesn't matter which revision is going to be reconstructed performance wise as every revision is indexed under a RevisionRootPage and the RevisionRootPages are indexed, too whereas an UberPage is the main entry point to the storage (quiet some ideas borrowed from ZFS).

I also have two fairly large projects former java, now completely mixed, more kotlin, and i had none of these problems. I can completely advise that you mix it if you want to migrate gradually. Having that said, yes, sometimes autoconversion isn't sufficient. My strategy was to autoconvert classes, look if they compile, if not, revert to Java, Take a look at what concept might cause troubles, quickly refactor it and convert again. From my experience it was mostly not so well written code that caused troubles. But i wouldn't call that troubles at all.

I dont know, my Projects were Java 8 already, like i said, No real problems. Of course java support is still better everywhere, expecting otherwise makes no sense :) but i am very impressed how good kotlin tooling in general worked and how easy it is to have a mixed codebase or to convert from java to kotlin. Of course one should not have the expectation that there wont be any effort, especially when the source code base is not in shape

im just sharing the benefit oof my experience on a codebase that has triggered endless restarts in porting. so many that i had to put it on the back burner.

I just want to not decourage people from trying it by themselves as it worked nicely for me :)

OP wanted to know the risks. not much point in playing down the risks

As I mainly want to provide the best possible Kotlin API (when the temporal data store is used as an embedded library), I could probably build a wrapper API, which mostly delegates to the Java-API, but has default parameter values, named parameters instead of builders, infix methods such as cursor moveTo 5, instead of cursor.moveTo(5) and such things. Maybe even providing a DSL 🙂 and I could start switching a small module instead of the core module at first.