Making Use of Sealed Classes in Java 

I love it. Text based formats rule. Everyone can read and work with them. *forever!* And they don't endanger your computer.

Glad you liked it

Could be in some cases... any example in mind?

Yes, it's a new form of "final". There's an escape hatch by declaring a sub-class "non-sealed". I hope it becomes best-practice to add one by library devs. Otherwise we end up in the same situation as language ecosystems where final is the default, where every other PR is asking to lift it or provide a hook.

I do not think that old libraries will seal existing public interfaces / classes, that will be a breaking change. Even with new code, we must only seal well defined closed class hierarchy. Two questions to ask before deciding to seal a class is "Do we use instanceof for deciding the behavior of our programs?" and "Does a default behavior make sense?" If the answer is Yes to first question and No to the second, only then we can think of sealing the class hierarchy. The compiler will ensure the correctness of our code automatically.

@@SourabhBhat What's often overlooked is that a closed class hierarchy within the library might make sense at the point of creation, but later on a user might want to override or extend this functionality in way not predicted by the library owner. Leading to discussions where the owner often takes a defensive stance "you're not using it as intended". Prime example within the Java ecosystem is JavaFX where so much is final that it gets really hard to customize anything (e.g. table layout). In essence sealed gives us two things: 1) library owners can thwart annoying support requests of the form "I tried to write my own implementation" and 2) you can safe the default in switch-case instanceof pattern matching and get exhaustiveness errors. 1) is questionable and 2) is aswell if you like me regard instanceof as code-smell / poor-mans polymorphism.

I think Venkat covered that at the beginning. Sealed hierarchies only make sense to model things for which there really are only a finite number of variations. So you might create a sealed hierarchy of stellar body types (Star, Planet, Satellite -> Moon, Asteroid), but not List.

​@@_SG_1 Sealing of interfaces/classes must be done very carefully indeed. Sealing any public interface defeats the whole purpose of an interface. Similarly, OOP heavily uses overriding of methods. However, there are a few cases where the logic changes based on an instanceof check. In such a situation the library developer has to throw an exception at runtime for any user defined class. This situation can be avoided by using a sealed class. I think this is where sealed class / interface can be used. In a code maintained by me, it makes sense to seal only a couple of internal interfaces. Nevertheless, it will make it very robust while extending the code. In one situation, I had to simulate a sealed class by defining an enum and an interface with one of the methods returning the object from the enum. I can get rid of the enum (and the method from interface) now.

looks like it will be used by people who are control freaks and we will have to deal with this when working with old libraries that use this.

In short, a "sealed class" is like an enum with benefits of a class. Consider you have written a library with an interface called Geometry having one abstract method area(), which is implemented by classes Square and Triangle within your library. The users of your library can pass either Square or Triangle object to a List for processing by your library. How can you prevent a user from passing an instance of say "class Tree implements Geometry" with their own implementation? How can you be sure of the contents of the list (that it contains only valid Geometry objects) when processing it within your library? Probably you will need to throw a runtime exception. If you use sealed classes this will be ensured automatically. The second use case will be in the future version of Java. Say that the Geometry interface is used at 10 different places in your code (and possibly more places by users of your library). If you decide to add a new class called Circle implementing Geometry in your library, how do you ensure that Circle is not being treated as a default case in one of those 10 places (and your library users)? The compiler cannot help you if it does not know about your class hierarchy. In the future, as Dr. Venkat said in this video, Sealed class will allow to switch over pre-defined sealed hierarchy thus the compiler will show error at those 10 places in your code during compile time. This will work even if a class is non-sealed. I think that sealed classes is a misunderstood feature but it will help both library developers and library users alike to ensure correctness of programs. This will make Java programs more robust and trustworthy.

@@SourabhBhat Can you demonstrate this with a Java Code so that I can execute in IDE. Can you demonstrate both the points .do share the Java code on a blog / github

you could say the same think for final. and there will be plenty of cases where you can foresee all possible scenarios at design time and we will avoid suprises with sealed classes.