Kotlin/Open Challenges and Room for Improvement

This page lists things that still can be done to improve the Kotlin packages and support on Gentoo.

Support for Java 9 and above
The Kotlin library packages are now eligible for a Java 9+ retrofit that incorporates their into the JARs being built. When the Kotlin library packages were initially created during July 2021, virtual/jdk:11 was not stabilized. Now that Java 11 is available as the system VM for users on stable keywords, it is time to update the Kotlin library packages and eclasses to let them support the Java Platform Module System (JPMS) introduced in Java 9.

Kotlin library packages that provide can be searched by finding files with this file name in the  directory under the Kotlin programming language project's source tree.

Kotlin library packages that both are available on Gentoo and provide include:
 * dev-java/kotlin-reflect
 * dev-java/kotlin-stdlib
 * dev-java/kotlin-stdlib-jdk7
 * dev-java/kotlin-stdlib-jdk8
 * dev-java/kotlin-test
 * dev-java/kotlin-test-junit

Please note that although, which is the basis of the Kotlin eclasses, supports compiling , Kotlin library packages'  files are supposed to be handled in a different way:
 * puts at the top level of the resulting JAR, whereas in Kotlin library packages' JARs, it is supposed to be stored at :


 * The file in the JAR of each Kotlin library package that provides  should contain the line  :

Therefore, instead of relying on, the Kotlin library packages' should be handled with custom logic. One possible solution is to implement the above behaviors in.

Target Java 1.8 instead of 1.6
Unlike the majority of Java packages in the Gentoo ebuild repository, which target Java 1.8, Kotlin library packages in the Spark overlay currently target Java 1.6 to follow the upstream. If the Kotlin packages and eclasses are aimed for submission to the Gentoo ebuild repository, this might become an issue that must be resolved.

Currently, the JDK and JRE dependencies of all Kotlin library packages are following the requirements of Gentoo Java Packing Policy:

The version specifications in the JDK and JRE atoms have implications to not only Portage's dependency resolver but also Java eclasses as to the values of the  and   options for. With  and ,  arguments will include. With  and , they will become   instead.

However, the upstream uses  to compile Java sources in most Kotlin library modules, and the Kotlin library packages for Gentoo are following suit. This breaks the consistency between the Java version specified in DEPEND and RDEPEND and the Java version specified for the  and   options.

To comply with the Java packaging conventions on Gentoo, the Kotlin library packages should compile Java sources with. This would require the following changes:
 * Change the value of KOTLIN_JAVA_WANT_SOURCE_TARGET in to
 * Change all occurrences of  in Kotlin compiler arguments in Kotlin eclasses and library ebuilds to
 * Test the changes thoroughly by running test suites of both the Kotlin library packages themselves and third-party Kotlin packages

Reproduce the JAR built by Gradle
As mentioned in User:Leo3418/Kotlin, there is not a way to reproduce from Portage a JAR for kotlin-reflect that is structurally identical to the upstream's pre-built JAR (which is presumably built with Gradle) yet, as the following command would fail:

Although this does not seem to affect the behavioral correctness of dev-java/kotlin-reflect, it would be great if a JAR whose structure is identical to the JAR pre-built by the upstream can be produced by the ebuild. Because kotlin-reflect does not have a test suite, the tests enabled by  are the only ways to verify the JAR built by the ebuild as of now.

The acceptance criterion of this task's result is that the aforementioned command completes without an error. After that, the test restriction on dev-java/kotlin-reflect can be lifted.

Build the package from source
kotlinx.coroutines is a Kotlin coroutines support extension that is not a Kotlin core library under the Kotlin programming project proper; yet it is a dependency of the Kotlin compiler. Currently, only a Gentoo package that directly installs the binary JAR pre-built by the upstream is available. Using the instructions in the Kotlin Package Maintainer Guide, it might be feasible to create a Gentoo package that builds kotlinx.coroutines from source, just like other Kotlin core libraries.

Automation tool for Kotlin library ebuild generation
Currently, maintenance of the Kotlin library packages heavily relies on a manual procedure to collect compiler arguments that the Kotlin Gradle plugin uses to build them, which is outlined in the Kotlin Package Maintainer Guide. As a more agile development model has been adapted by the Kotlin programming language project since Kotlin 1.5, the upstream has started to deliver a new feature release every six months. With this release cadence, the feasibility of relying on the manual procedure has been compromised.

Luckily, the bulk of the compiler arguments collection procedure involve only invocations of and common Unix utilities like  and, making it possible to automate some, if not all, steps in the procedure. A tool that automates these steps to the maximum possible extent could help Kotlin library package maintainers cope with the rapid release schedule adapted by the upstream.

The automation tool can either generate complete and installable ebuilds or create partial ebuilds that the maintainers can amend to make them fully-functional. Ideally, it should at least be able to run a Gradle task in the Kotlin programming language project's source tree with the  option enabled, collect the debug logs, wrangle with the logs to find the arguments to the Kotlin compiler and, and output the corresponding values of  variables like KOTLIN_COMMON_SOURCES_DIR. A great implementation of such a tool should also be general enough so it can create ebuilds for not just the Kotlin library packages but most third-party Kotlin packages as well.