kotlinx.coroutines icon indicating copy to clipboard operation
kotlinx.coroutines copied to clipboard

Published 20 hours ago • verified publisher icon Kotlin

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

Open zajac opened this issue 3 years ago • 7 comments

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.

zajac avatar Jan 10 '22 13:01 zajac

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 avatar Jan 10 '22 13:01 qwwdfsad

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

qwwdfsad avatar Jan 10 '22 13:01 qwwdfsad

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 avatar Jan 10 '22 15:01 zajac

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

zajac avatar Apr 28 '22 23:04 zajac

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

qwwdfsad avatar Apr 28 '22 23:04 qwwdfsad

+1 on a fix for this please.

big-andy-coates avatar May 11 '22 09:05 big-andy-coates

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

qwwdfsad avatar Feb 20 '23 13:02 qwwdfsad