Η αρχιτεκτονική των sealed classes
Η εισαγωγή των sealed classes στη Java (JEP 409) έφερε μια σημαντική αλλαγή στον τρόπο διαχείρισης ιεραρχιών κλάσεων, επιτρέποντας στους προγραμματιστές να περιορίσουν ρητά τους επιτρεπόμενους υποτύπους. Αυτή η προσέγγιση φέρνει τη Java πιο κοντά σε λειτουργικές γλώσσες (functional programming) με αλγεβρικούς τύπους δεδομένων, προσφέροντας αυξημένη ασφάλεια μέσω του exhaustive pattern matching.
Το ζήτημα της ξεχωριστής μεταγλώττισης (separate compilation)
Ενώ ο compiler διασφαλίζει την εξαντλητικότητα κατά το compile-time, η αρχιτεκτονική της Java επιτρέπει την ανεξάρτητη μεταγλώττιση διαφορετικών modules. Εάν ένα library εκθέτει ένα sealed interface και προσθέσει έναν νέο υποτύπο σε μια μεταγενέστερη έκδοση, οι εφαρμογές που εξαρτώνται από αυτό το library και δεν έχουν επαναμεταγλωττιστεί, ενδέχεται να αντιμετωπίσουν runtime σφάλματα. Συγκεκριμένα, το MatchException εμφανίζεται όταν το runtime συναντά έναν τύπο που δεν υπήρχε κατά τη στιγμή της μεταγλώττισης του καταναλωτή.
Στρατηγικές χρήσης σε δημόσια API
Η ανάλυση υποδεικνύει ότι η χρήση sealed types σε δημόσια API απαιτεί ιδιαίτερη προσοχή. Ενώ προσφέρουν εξαιρετική ασφάλεια εντός ενός κλειστού συστήματος (όπου ο έλεγχος του build pipeline είναι πλήρης), η έκθεσή τους σε εξωτερικούς καταναλωτές μπορεί να δημιουργήσει εύθραυστα συμβόλαια. Οι μηχανικοί θα πρέπει να αξιολογούν αν η ανάγκη για αυστηρό pattern matching υπερτερεί του κινδύνου πρόκλησης ασυμβατότητας σε μελλοντικές εκδόσεις του API.