Re:Java's records, Lombok's data, and Kotlin's data classes
by oftenwrong on Friday May 07, 2021 @04:20PM
(#27080426)
Sealed classes are (most likely) going to be in the next version of Java, Java 17: https://openjdk.java.net/jeps/409
Re:Java's records, Lombok's data, and Kotlin's data classes
by aphexairlines on Friday May 07, 2021 @09:51PM
(#27082896)
You do it like this: https://github.com/Kotlin/kotlinx.serialization/blob/master/...
Re:Java's records, Lombok's data, and Kotlin's data classes
by TJSomething on Friday May 07, 2021 @03:40PM
(#27080073)
In traditional Java, you're probably using Jackson for your JSON. You can achieve those sorts of results by specifying the classes and type tags in annotations on an abstract Either class to use Jackson's polymorphic serialization feature.
Re:Java's records, Lombok's data, and Kotlin's data classes
by balefrost on Friday May 07, 2021 @04:04PM
(#27080299)
The point of sealed classes is that you have a known number of possible representations. So you can have `when` blocks that exhaustively check all possibilities. Having an open class hierarchy would not work for that purpose.
Re:Java's records, Lombok's data, and Kotlin's data classes
by __jem on Friday May 07, 2021 @09:17PM
(#27082722)
this technique works with sealed classes, i’ve done it before. it throws a runtime exception if it can’t identify the discriminant.
Re:Java's records, Lombok's data, and Kotlin's data classes
by winrid on Saturday May 08, 2021 @03:14AM
(#27084715)
The easiest way is with GSON:
https://mkyong.com/java/how-do-convert-java-object-to-from-j...
You would just have to have annotations on the enum names to get the lowercase values in your example json.
I was also kind of surprised to see the article talking about algebraic data types... table stakes for ADTs is sum types and I have missed them considerably in the Java ecosystem.
Kotlin has something like them with sealed classes, although I'm a newcomer to the Kotlin and Spring Boot ecosystem so I don't see explicitly how I make some simple case like JSON
turn into some structure like: rather than the hacky version that you have to do in relational databases and Java which don't support such things, Like I’m not saying that there’s no way, I’m sure there’s a way... just that the ecosystem seems so hesitant to embrace sum types that like the above sealed class is widely viewed as a hack and there is no statement about “here is how you actually use sum types for everything in your Spring application with Kotlin.”Was gonna give the choose-your-own-adventure example of why sum types are handy and how you have to kind of hack around them with inheritance when you don't have them but it occurs to me that anyone who has stuck with this comment this far probably already has some familiarity with this?