Updating to 1.2.0-alpha01-dev741 from dev-731 results in a crash when compiling: ```java.lang.Incom...

# compose-desktop

[eygraber]

Updating to 1.2.0-alpha01-dev741 from dev-731 results in a crash when compiling:

java.lang.IncompatibleClassChangeError: Found interface org.jetbrains.kotlin.ir.types.IrSimpleType, but class was expected
	at androidx.compose.compiler.plugins.kotlin.analysis.StabilityInferencer.stabilityOf(Stability.kt:420)
	at androidx.compose.compiler.plugins.kotlin.analysis.StabilityInferencer.stabilityOf$default(Stability.kt:383)
	at androidx.compose.compiler.plugins.kotlin.lower.AbstractComposeLowering.stabilityOf(AbstractComposeLowering.kt:178)

[eygraber]

Full stack trace can be seen here https://github.com/eygraber/portal/runs/7198509062?check_suite_focus=true

[Lucas]

Same here

[eddie]

@eygraber did you update to Kotlin 1.7?

[Mitchell Syer]

Based on the branch the workflow ran on, doesnt seem like it. Still on 1.6.21

[Lucas]

Should that be mandatory tho?

[Mitchell Syer]

It is mandatory, the compose gradle plugin has always had specific versions of Kotlin it relies on

[Landry Norris]

Also, 1.7 is Kotlin’s version of a ‘breaking change’. You can’t guarantee compatibility with 1.6.x

[Lucas]

I see. The problem for me is that when i upgrade to kotlin 1.7 i get
<http://com.android.tools.r8.internal.nc|com.android.tools.r8.internal.nc>: Sealed classes are not supported as program classes
Stackoverflow suggests this should be corrected on agp 7.1, but i'm using 7.2.1 and still get this error
This with java 17, didnt try with java 11

[Lucas]

Java 11 works

[eygraber]

Just updated the branch to use Kotlin 1.7 and it works. Missed the release note about 1.7 support.

[Kirill Grouchnikov]

This whole situation with 1.2 alpha / rc drops and Kotlin 1.6.21 / 1.7.0 is messy

[Landry Norris]

Yeah. And there’s extra confusion for those of us on compose-jb, where the version is still 1.2.0-alpha01-devxxx, but different versions can use different 1.2.0 alphas. It gets a bit difficult to tell what version of Compose I’m actually using.

[Kirill Grouchnikov]

I just upgraded Aurora to dev741 and 1.7.0. Seems to be fine

[Landry Norris]

Yeah. 741 brought in 1.7 support. I guess that means it uses the stable compose compiler.

[Kirill Grouchnikov]

This one was unexpected though. The compiler told me that the when conditions are not exhaustive

[Lucas]

We cant blame the compose team, those are alpha versions after all

[Landry Norris]

Yes. I believe that’s required in Kotlin 1.7

[Kirill Grouchnikov]

But the enum has only two values

[Landry Norris]

Interesting. Maybe a compiler bug?

[Landry Norris]

I’d assume the alpha status of compose-jb is referring to iOS/macOS support? I know those are still experimental. It’s just a little confusing that the versions are similar (1.2.0 pre-releases), but don’t match the underlying compose.

[Kirill Grouchnikov]

Yeah, probably. Didn't feel like I wanted to dive deep into it

[Landry Norris]

Yeah. I always add an else -> error("Case is not handed $whenParameter") if it tells me I need an else.

[Lucas]

Yeah, and CfW Canvas also. But still, its an alpha version so i guess things like that should be acceptable.

[Lucas]

Not the exaustive when tho, that doesnt seem compose related

[Landry Norris]

I thought CfW canvas is out of experimental as of a few months ago. Is it in some beta state right now?

[Landry Norris]

Yeah. That’s a Kotlin 1.7 change.

[Landry Norris]

But if he’s handling both enums, that should pick up as exhaustive.

[Lucas]

It kinda works. Not sure about the official status tho. Textfields are still buggy (cant handle backspaces basically), but you could make some simple app work

[Lucas]

I'm developing an android app (a food marketplace) and i'm hoping i'm going to be able to make it work on web with canvas in a couple months, even if still in alpha or beta.

[Lucas]

my exaustive test enum works tho

[Kirill Grouchnikov]

This is the only place in Aurora that I had to add that extra else. All the others are fine.

[Landry Norris]

The enum isn’t open, right? I’m wondering if it thinks there’s a way for a module to add another option.

[Landry Norris]

Is separatorOrientation nullable?

[Lucas]

yeah nullability could be the problem

[Kirill Grouchnikov]

Yes, nullable

[Lucas]

then the null option is missing

[Landry Norris]

That’s why. That makes null a valid path.

[Kirill Grouchnikov]

Eek, I guess so

[Landry Norris]

1.7 requires that all when are exhaustive. Nullable whens should handle this case explicitly.

[Kirill Grouchnikov]

I might be able to make it non-nullable though. Looks like I always set it 🙂