Any usage of the kotlinx.coroutines.debug package, for example import kotlinx.coroutines.debug.DebugProbes results in:
[JAVA_MODULE_DOES_NOT_EXPORT_PACKAGE] Symbol is declared in module 'kotlinx.coroutines.debug' which does not export package 'kotlinx.coroutines.debug'
The split package between kotlinx.coroutines.core and kotlinx.coroutines.debug of package kotlinx.coroutines.debug must be solved and cannot be hacked around by commenting its exports statement in kotlinx.coroutines.debug's module-info.java π’.
To continue the investigation, using custom module loading code, we merged kotlin.stdlib, kotlinx.coroutines.core and kotlinx.coroutines.debug modules at runtime:
kotlinx.coroutines.core and kotlinx.coroutines.debug to mitigate the package split
kotlin.stdlib to mitigate the circular dependency between kotlinx.coroutines.debug and kotlin.stdlib after bytebuddy injection at runtime
kotlin.stdlib --- (due to injected code) --> kotlinx.coroutines.debug -> kotlinx.stdlib
That provided us with a few more information about what is wrong with the current module-info.java:
some statements are missing (probably coming from the shadowing of bytebuddy):
requires com.sun.jna;
exports kotlinx.coroutines.repackaged.net.bytebuddy.agent to com.sun.jna;
these redundant (bytebuddy being shadowed in the same module) requires crashes at runtime:
when used in production, the current declaration and structure of kotlinx-coroutines-debug jar forces users to bring in jars to their runtime module path to fulfill:
JUnit is not something one would want in production runtime module path π ...
I did not find any suitable workaround to unblock ourselves. The only solution I see is to:
fix the split package of kotlinx.coroutines.debug package in kotlinx.coroutines.core and kotlinx.coroutines.debug (providing an additional jar for kotlinx-coroutines-debug with probably a new name like kotlinx-coroutines-debug2 π)
fix module-info.java issues pointed in point 1 and 2
extract junit related utilities currently present in kotlinx.coroutines.debug.junit4 and kotlinx.coroutines.debug.junit5 packages into additional jars (e.g. kotlinx-coroutines-debug-junit4 and kotlinx-coroutines-debug-junit5), and remove requires statements of point 3
Any usage of the
kotlinx.coroutines.debug
package, for exampleimport kotlinx.coroutines.debug.DebugProbes
results in:The split package between
kotlinx.coroutines.core
andkotlinx.coroutines.debug
of packagekotlinx.coroutines.debug
must be solved and cannot be hacked around by commenting itsexports
statement inkotlinx.coroutines.debug
'smodule-info.java
π’.To continue the investigation, using custom module loading code, we merged
kotlin.stdlib
,kotlinx.coroutines.core
andkotlinx.coroutines.debug
modules at runtime:kotlinx.coroutines.core
andkotlinx.coroutines.debug
to mitigate the package splitkotlin.stdlib
to mitigate the circular dependency betweenkotlinx.coroutines.debug
andkotlin.stdlib
after bytebuddy injection at runtimekotlin.stdlib
--- (due to injected code) -->kotlinx.coroutines.debug
->kotlinx.stdlib
That provided us with a few more information about what is wrong with the current
module-info.java
:some statements are missing (probably coming from the shadowing of bytebuddy):
these redundant (bytebuddy being shadowed in the same module)
requires
crashes at runtime:when used in production, the current declaration and structure of
kotlinx-coroutines-debug
jar forces users to bring in jars to their runtime module path to fulfill:JUnit is not something one would want in production runtime module path π ...
I did not find any suitable workaround to unblock ourselves. The only solution I see is to:
kotlinx.coroutines.debug
package inkotlinx.coroutines.core
andkotlinx.coroutines.debug
(providing an additional jar forkotlinx-coroutines-debug
with probably a new name likekotlinx-coroutines-debug2
π)module-info.java
issues pointed in point 1 and 2kotlinx.coroutines.debug.junit4
andkotlinx.coroutines.debug.junit5
packages into additional jars (e.g.kotlinx-coroutines-debug-junit4
andkotlinx-coroutines-debug-junit5
), and removerequires
statements of point 3