I'm getting a `ClassCastException` with the follo...

# compose

[ste]

I'm getting a ClassCastException with the following minimal snippet:

var something by rememberSaveable { mutableStateOf(0) }
val value by rememberSaveable(something) { mutableStateOf("Hello") }
val somethingElse by rememberSaveable { mutableStateOf(false) } // !!!

println("value: $value") // !!!

Box(
    modifier = Modifier
        .fillMaxSize()
        .clickable { something += 1 }
)

However, after something is changed, it throws java.lang.ClassCastException: java.lang.Boolean cannot be cast to java.lang.String on configuration change. I know the example doesn't make sense, but is this a bug or whatsoever?

[ste]

It looks like it's messing value and somethingElse value restores

[Andrey Kulikov]

if you have a stable reproducible example please file a bug!

[Zach Klippenstein (he/him) [MOD]]

i’ve got a test that reproduces

[Zach Klippenstein (he/him) [MOD]]

removing the key for value, or adding one to somethingElse, seems to avoid the crash

[Zach Klippenstein (he/him) [MOD]]

looks like somehow the saved values are in the wrong order in the registry’s list

[Zach Klippenstein (he/him) [MOD]]

so it looks like this happens because `value`’s saved value provider is removed then re-added to the list of providers when the key changes. So after the first composition, the list is {0, "Hello", false}, then after the button is clicked, it’s {1, false, "Hello"}. If you haven’t filed a bug yet, i will.

[Andrey Kulikov]

indeed, thanks for the investigation. feel free to assign a bug on me, I will take a look

[Zach Klippenstein (he/him) [MOD]]

https://issuetracker.google.com/214396074

[Andrey Kulikov]

a workaround would be to reorder the val declarations so the one with keys is defined the last one. meaning that somethingElse is defined before value in your example

[Zach Klippenstein (he/him) [MOD]]

I think another workaround would be to hoist all three values into a separate object and just use rememberSaveable once. Only then you’d need to manage re-initializing the "Hello" state when something changed, but since i’m guessing your real code that triggered this is more complex i’m guessing you might eventually want to factor out a state holder anyway.

[ste]

Thanks for investigating!