Are `sealed class` really not supported yet on And...

# android

[CLOVIS]

Are sealed class really not supported yet on Android?

{
  "kind": "error",
  "text": "com.android.tools.r8.internal.Jc: Sealed classes are not supported as program classes",
  "sources": [
    {
      "file": "[PATH REDACTED]/NavigationMenu.class"
    }
  ],
  "tool": "D8"
}

[mattinger]

I've never had a problem with a sealed class. I use them a*ll the time*

[Josh Eldridge]

I would look into the proguard setup you have going on, sealed classes are supported by default

[Priyatanu Dey]

It's a kotlin language feature. It should be supported

[CLOVIS]

@Priyatanu Dey it doesn't compile though.

@Josh Eldridge I'm new to Android, this is a brand new project generated by AS, with multiple additional JVM+JS modules. The progguard-rules.pro file is empty (just the comments to explain it).

[Mark Murphy]

FWIW, I demonstrate the use of sealed classes in Android Kotlin projects in this free book and this free book, among others.

[Josh Eldridge]

Have you stumbled upon this SO post? https://stackoverflow.com/questions/73453524/what-is-causing-this-error-com-android-tools-r8-internal-nc-sealed-classes-are

[CLOVIS]

Thanks @Josh Eldridge, it was a Java 17 issue in one of the other modules. I can't believe Android is this late.

[J6ey]

why use sealed class when there's interface and abstract classes already

[Josh Eldridge]

Sealed classes are used to represent a hierarchical structure and give control of the known subclasses at compile-time, abstract classes do not provide this. I'd recommend checking out the official docs and the kotlin academy article here for a bit more info/usages.
https://kotlinlang.org/docs/sealed-classes.html
https://kt.academy/article/ek-sealed-classes

[Priyatanu Dey]

It's because limiting the amount of sub classes at compile time

[mattinger]

@J6ey Because regular interfaces and abstract classes allow implementing/subclassing by unknown entities. This leads to non deterministic code. Sealed classes are a great way to prevent subclassing so you can have deterministic code in situations where you know at compile time what all the possibilities are. Think of them like enums, but for situations where the possibilities don't all have the same data fields.