codegen-java/kotlin: Support generating sealed classes #249

New Issue

adam · 2025-12-30T01:22:41+01:00

adam commented

2025-12-30 01:22:41 +01:00

Originally created by @odenix on GitHub (Nov 12, 2024).

It would be very nice to generate sealed Java/Kotlin classes whenever possible. This would improve code comprehension, pattern matching, and the IDE experience.

Potential solutions:

Infer which abstract and open Pkl classes can be sealed in Java/Kotlin.
At a minimum, this would require passing all Pkl modules at once to Java/KotlinCodeGenerator so that it can check if a class is subclassed in another module. Currently, Java/KotlinCodeGenerator only accepts a single module whereas CliJava/KotlinCodeGenerator accepts multiple.
Support sealed classes in Pkl. This feels like a cleaner solution and could prove equally useful as supporting open vs. non-open classes.

Originally created by @odenix on GitHub (Nov 12, 2024). It would be very nice to generate *sealed* Java/Kotlin classes whenever possible. This would improve code comprehension, pattern matching, and the IDE experience. Potential solutions: 1. Infer which abstract and open Pkl classes can be sealed in Java/Kotlin. At a minimum, this would require passing all Pkl modules at once to Java/KotlinCodeGenerator so that it can check if a class is subclassed in another module. Currently, Java/KotlinCodeGenerator only accepts a single module whereas CliJava/KotlinCodeGenerator accepts multiple. 2. Support sealed classes in Pkl. This feels like a cleaner solution and could prove equally useful as supporting open vs. non-open classes.

adam commented

2025-12-30 01:22:43 +01:00

@bioball commented on GitHub (Nov 13, 2024):

Infer which abstract and open Pkl classes can be sealed in Java/Kotlin.

Without a sealed in Pkl, there's no way to ensure that the provided set of classes is exhaustive. For example:

Library publishes Pkl bindings + Java codegen'd classes
Application uses library, extends Pkl classes and does is own codegen

@bioball commented on GitHub (Nov 13, 2024): > Infer which abstract and open Pkl classes can be sealed in Java/Kotlin. Without a `sealed` in Pkl, there's no way to ensure that the provided set of classes is exhaustive. For example: 1. Library publishes Pkl bindings + Java codegen'd classes 2. Application uses library, extends Pkl classes and does is own codegen

adam commented

2025-12-30 01:22:43 +01:00

@odenix commented on GitHub (Nov 13, 2024):

I think the conclusion is that moving forward with this feature would require a sealed SPICE.

@odenix commented on GitHub (Nov 13, 2024): I think the conclusion is that moving forward with this feature would require a `sealed` SPICE.

adam commented

2025-12-30 01:22:44 +01:00

@bioball commented on GitHub (Nov 13, 2024):

Yeah; I think that's right

@bioball commented on GitHub (Nov 13, 2024): Yeah; I think that's right

adam commented

2025-12-30 01:22:44 +01:00

@odenix commented on GitHub (Nov 15, 2024):

How about reserving the keyword sealed for now?

@odenix commented on GitHub (Nov 15, 2024): How about reserving the keyword `sealed` for now?

adam commented

2025-12-30 01:22:44 +01:00

@bioball commented on GitHub (Jan 24, 2025):

I'm okay with that!

@stackoverflow, @holzensp: thoughts?

@bioball commented on GitHub (Jan 24, 2025): I'm okay with that! @stackoverflow, @holzensp: thoughts?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pkl#249