Are `sealed class` really not supported yet on Android? ```{"kind":"error","text":"com.android.tools...
c
Are
sealed class
really not supported yet on Android?
Copy code
{
  "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"
}
m
I've never had a problem with a sealed class. I use them a*ll the time*
☝🏻 1
j
I would look into the proguard setup you have going on, sealed classes are supported by default
p
It's a kotlin language feature. It should be supported
c
@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).
m
FWIW, I demonstrate the use of sealed classes in Android Kotlin projects in this free book and this free book, among others.
c
Thanks @Josh Eldridge, it was a Java 17 issue in one of the other modules. I can't believe Android is this late.
j
why use sealed class when there's interface and abstract classes already
j
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
❤️ 2
p
It's because limiting the amount of sub classes at compile time
m
@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.
2062 Views