Updating to 1.2.0-alpha01-dev741 from dev-731 resu...
# compose-desktop
e
Updating to 1.2.0-alpha01-dev741 from dev-731 results in a crash when compiling:
Copy code
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)
😢 2
l
Same here
e
@eygraber did you update to Kotlin 1.7?
m
Based on the branch the workflow ran on, doesnt seem like it. Still on 1.6.21
l
Should that be mandatory tho?
m
It is mandatory, the compose gradle plugin has always had specific versions of Kotlin it relies on
l
Also, 1.7 is Kotlin’s version of a ‘breaking change’. You can’t guarantee compatibility with 1.6.x
l
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
Java 11 works
🙏 2
e
Just updated the branch to use Kotlin 1.7 and it works. Missed the release note about 1.7 support.
k
This whole situation with 1.2 alpha / rc drops and Kotlin 1.6.21 / 1.7.0 is messy
💯 1
l
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.
k
I just upgraded Aurora to dev741 and 1.7.0. Seems to be fine
l
Yeah. 741 brought in 1.7 support. I guess that means it uses the stable compose compiler.
k
This one was unexpected though. The compiler told me that the
when
conditions are not exhaustive
l
We cant blame the compose team, those are alpha versions after all
l
Yes. I believe that’s required in Kotlin 1.7
k
But the
enum
has only two values
l
Interesting. Maybe a compiler bug?
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.
k
Yeah, probably. Didn't feel like I wanted to dive deep into it
l
Yeah. I always add an
else -> error("Case is not handed $whenParameter")
if it tells me I need an else.
l
Yeah, and CfW Canvas also. But still, its an alpha version so i guess things like that should be acceptable.
Not the exaustive when tho, that doesnt seem compose related
l
I thought CfW canvas is out of experimental as of a few months ago. Is it in some beta state right now?
Yeah. That’s a Kotlin 1.7 change.
But if he’s handling both enums, that should pick up as exhaustive.
l
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
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.
my exaustive test enum works tho
k
This is the only place in Aurora that I had to add that extra
else
. All the others are fine.
l
The enum isn’t open, right? I’m wondering if it thinks there’s a way for a module to add another option.
Is separatorOrientation nullable?
l
yeah nullability could be the problem
k
Yes, nullable
l
then the null option is missing
l
That’s why. That makes null a valid path.
k
Eek, I guess so
l
1.7 requires that all when are exhaustive. Nullable whens should handle this case explicitly.
k
I might be able to make it non-nullable though. Looks like I always set it 🙂