Compose Compiler 2.0.20-Beta2: NoClassDefFoundError: ComposeDefaultImpls with ExposedDropdownMenuBox [357878245]

Fixed

Bug

Status Update

No update yet.

Description

li...@gmail.com

created issue #1

Aug 7, 2024 10:38AM

Jetpack Compose version: 1.6.8
Jetpack Compose component used: ExposedDropdownMenuBox
Kotlin version: 2.0.20-Beta2/2.0.20-RC

Reproduce

I made a Reproduction Sample: https://github.com/LionZXY/Kotlin220Bug

Steps repoduce:

Try launch app via Emulator/Device

Actual Behavior: Crash in runtime

 java.lang.NoClassDefFoundError: Failed resolution of: Landroidx/compose/material/ExposedDropdownMenuBoxScope$ComposeDefaultImpls;
  at com.lionzxy.kotlinbug.MainActivityKt$Content$1$2.invoke(MainActivity.kt:42)
  at com.lionzxy.kotlinbug.MainActivityKt$Content$1$2.invoke(MainActivity.kt:41)
  at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:118)
  at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:35)

Expected Behavior: No crashing

If you change the Kotlin version here to 2.0.10 (or 2.0.20-Beta1), the problem goes away

Stack trace (if applicable):

 java.lang.NoClassDefFoundError: Failed resolution of: Landroidx/compose/material/ExposedDropdownMenuBoxScope$ComposeDefaultImpls;
  at com.lionzxy.kotlinbug.MainActivityKt$Content$1$2.invoke(MainActivity.kt:42)
  at com.lionzxy.kotlinbug.MainActivityKt$Content$1$2.invoke(MainActivity.kt:41)
  at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:118)
  at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:35)

Comments

as...@google.com <as...@google.com> Aug 7, 2024 03:11PM

Reassigned to as...@google.com.

as...@google.com <as...@google.com> #2Aug 8, 2024 03:54PM

Sorry forgot to change the issue title to something that makes more sense.

Main question is, can the same instance of a worker be used in multiple places? And if so, it looks like things are broken.

li...@gmail.com <li...@gmail.com> #3Aug 8, 2024 04:12PM

I think the issue here is that we should explicitly disallow more than one instance of the same work request in a chain. What's happening here is correct - each work request runs exactly once.

as...@google.com <as...@google.com> #4Aug 8, 2024 04:18PM

Can you give us a sample app where you see the problems occur? It's a little hard to tell from your logs because both sets of output are using the same exact work requests and it's hard to tell when you enqueued them and what order you're running them in. Did you use them for both the unique and non-unique work?

cj...@gmail.com <cj...@gmail.com> #5Aug 19, 2024 10:03PM

In the last example 2 SnapshotWorkers were run, even though I pass the same instance to both chains.

I think I would expect the same instance to be able to be used multiple times, but runs after it's first would be 'skipped'. What do you think of that concept?

as...@google.com <as...@google.com> #6Aug 20, 2024 09:44AM

Only one WorkContinuation.combine() is run per log. Ok I can see about creating a sample app.

cj...@gmail.com <cj...@gmail.com> #7Aug 20, 2024 05:23PM

WorkManager should explicitly disallow situations where a workrequest has the same item as both a prerequisite and a dependent. This is happening in your graphs.

as...@google.com <as...@google.com> Sep 3, 2024 03:42PM

Marked as fixed.