Question: partial Kotlin-ization of the project to support older Java

[DanySK]

Hi, I'm maintaining several FOSS components used in research, some of which depend on this great library (thanks!). The software I produce often needs to be kept compatible with Java 11 and even Java 8. This is preventing me from using the latest jpx.

The big problem with not using more recent Java versions is that you miss several useful features. However, I believe there is a reasonable work around: slowly converting the projects to Kotlin-JVM. I am adopting this approach in several projects with good results. The learning curve for a Java programmer is reasonably flat (even though writing idiomatic code requires a bit of experience), it generates Java8-compatible bytecode, and (as far as I could test it) it produces software that is performance-wise comparable with the latest Java versions (my guess is that most of the performance comes from the newer JVMs rather than new bytecode versions).

Kotlin can live with Java and can be adopted step by step, by converting only those classes that use post-Java 11 features, until we are back to Java 11 support.

Documentation-side, Dokka can be used to generate the Javadoc for a mixed Kt-Java project.

Is this strategy something that you find appealing? If so, I could contribute with multiple pull requests:

1. enabling Kotlin support in the build system
2. porting classes to Kotlin until we achieve Java 11 compatibility
3. using the Gradle toolchains to ensure Java consistency

Let me know

[jenetics]

I'm not in principle against a Kotlin-Implementation of the JPX library. The main constraints are my limitied resources for maintaining it. I still want to keep a Java implementation, because I use my side-projects for learning and using new Java features. Thats also the reason for updating the libraries to the current long-term versions of Java.

So, it's a reasonable request to have support for older Java version, but I can't do this, due to constraints in my time budget, I want and can invest into this library.

[DanySK]

I could spend some of my free time, but before investing it I'd like to understand what will be the final state of affairs.

I can see two alternatives:

1. The pure-Java implementation remains the reference implementation, updates and PRs target that version, and must then get ported to the hybrid one
2. The hybrid implementation becomes the reference implementation, updates and PRs target that version, patches get ported to the pure java branch

In the first scenario, I can as well fork the project and release a new artifact. In the latter scenario, there would potentially be an additional maintenance burden on your side, if patches modify the Kotlin part of the project. This can be minimized by converting only the files that use Java 12+ features and keeping as much as possible in pure Java, but cannot be elided entirely.

[jenetics]

I also see a 3rd option: Multi release Jars. Will work for Java 9+. I haven't experimented with this feature and don't know how it is supported by the IDE (IntelliJ) and/or Gradle. If you want to take the initial burdon on this solution, I can imagine to support it.

[DanySK]

On the matter, I largely agree with this Gradle blog post, it's the wrong answer to a correct question. However, I think something similar would be achievable via Gradle's own "variants". I need to investigate the matter better, though.