Package kotlinx.coroutines.debug is split between two distinct artifacts

Kotlin / kotlinx.coroutines

Library support for Kotlin coroutines

Apache License 2.0

13.03k stars 1.85k forks source link

Package kotlinx.coroutines.debug is split between two distinct artifacts #3128

Open zajac opened 2 years ago

zajac commented 2 years ago

Subj prevents us from depending on both of them in any JPMS module and even from having both of them on the module-path simultaneously. Maybe there are other instances of split-package in coroutines lib, which also need to be addressed.

qwwdfsad commented 2 years ago

We indeed have a split package:

One in kotlinx-coroutines-debug module that has a user-facing [experimental] API for dynamic debug probes attach/detach and programmatic work with a debugger.
One in kotlinx-coroutines-core. This part is not user-facing, but stable -- it is used by both IDEA and the upcoming Android Studio debugger to obtain information about coroutines, and cannot be changed in a backwards-incompatible manner without breaking coroutine debugger in existing IDEAs.

The problem seems significant as it prevents us from properly adopting JPSM with the only potential solution to rename the package in kotlinx-coroutines-debug

qwwdfsad commented 2 years ago

Meanwhile, it seems like I've found a workaround for JPSM-projects: the project has to declare an additional module, e.g. fleet-coroutines-debug that has to repackage, shade and export kotlinx-coroutines-debug under a different root package (e.g. fleet.kotlinx.coroutines.debug). All other modules should depend on the artificial "debug" module for debug capabilities

zajac commented 2 years ago

Maybe we can do that once and for all JPMS projects? To have a separate artifact that does particularly that, which is not compatible with the original one, but allows it to be required by JPMS modules

zajac commented 2 years ago

when is 1.7 scheduled? may we have some artifact earlier than that? Kinda critical for us.

qwwdfsad commented 2 years ago

We already discussed it, it won't be "fixed" in 1.7.0, because such change should be processed with proper deprecation cycle; unfortunately, we cannot just change the package, neither we are going to maintain multiple artifacts that differ only in package and open the door to JAR hell.

If it is critical, I suggest applying the workaround I've provided above

big-andy-coates commented 2 years ago

+1 on a fix for this please.

qwwdfsad commented 1 year ago

https://youtrack.jetbrains.com/issue/KTIJ-24102/Change-coroutine-debugger-implementation-to-use-a-new-package issue to keep track of, this is the pre-requisite to split-package removal