Yes, please do this!

Hi @daniel-jasinski,
To better understand the specific use cases and motivations behind this feature request, we would greatly appreciate it if you could provide us with more details.

• What specific scenarios or projects would benefit from the integration of kotlinx.collections.immutable into the Java module system?
• Are there any challenges or limitations you've encountered that this feature would help address?

Your insights will be invaluable in guiding our decision-making process and ensuring that any enhancements align closely with the needs of our user community.

Hi,
We are developing a desktop application with Compose-Multiplatform UI.
The app is packaged using JDK jpackage utility, and would like to make the app modular using JMS for various build hygiene and performance reasons. It would simplify our process if we did not have to do workarounds for some of our non-modular dependencies.

@qurbonzoda The development experience without a module descriptor can be quite frustrating, for example, in IDEA:

But, from Gradle:

> Task :protocol:compileJava FAILED
/.../module-info.java:9: error: module not found: kotlinx.collections.immutable.jvm
  requires kotlinx.collections.immutable.jvm;

This is probably either originating from a Automatic-Module-Name, or from a generated module name from somewhere in IntelliJ. I'm not sure where, but the suggestion is wrong, and if I don't add the incorrect requires ... line, the code flags as an error in the IDE.

What specific scenarios or projects would benefit from the integration of kotlinx.collections.immutable into the Java module system?

Any scenario where the developer is using KotlinX Immutable Collections and wishes to distribute or package their own library or application with JPMS. Without the module descriptor in this library, the author has these choices:

• Build with the library on the classpath. This defeats the optimizations and security guarantees provided by the module system, and is how the library works now.

• Patch the module to make it an automatic module. This is done by adding Automatic-Module-Name to the JAR manifest for kotlinx-collections-immutable; it's not very easy to do this in build tools, and is suboptimal anyway, even if it was included in the JAR, because automatic modules can read the classpath, which (again) unfortunately defeats the optimizations and security guarantees provided by the module system.

• Stop using the library. Because there is no alternative, the user has the hard choice to ditch JPMS entirely or this library, and ultimately, if the user has bought into JPMS already, the cost here is very high compared to just not using this code.

This is, unfortunately, the JPMS hand dealt to all of us by Oracle. Because of all the reasons above, KotlinX Serialization builds with a module-info, as do coroutines, datetime, and atomicfu. Thus, a user adding the full suite of KotlinX libraries may be in for a surprising and frustrating realization when this library does not provide one.

Edit: For anyone running into this issue in IDEs, you can suppress with:

@Suppress("JAVA_MODULE_DOES_NOT_DEPEND_ON_MODULE")

@sgammon, thank you for your elaborate answer. We will aim to include module-info in our upcoming releases.

@qurbonzoda you can probably take a look at https://github.com/Kotlin/kotlinx.coroutines/blob/master/buildSrc/src/main/kotlin/Java9Modularity.kt to save an effort

@qwwdfsad / cc @qurbonzoda I've posted a PR which uses Java9Modularity to ship a module-info. Let me know if you need any changes or have other review notes.