This would be an interesting mechanism in multiple development team env. Senior architect can define a certain set of classes to be must extended but extended only once. Plus you can permit who can extend. Utilizing this in designs would be something to keep in mind.
Let's suppose Java Seals List Interface only for Lists defined by java then i will not be able to extend List to create my own definition rt ? Open for extension and closed for modification => now Sealed for modification. Hopping all these are happening for good and for reducing the runtime / unexpected errors we get.
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.
explain to me like i'm 5, what problem does it solve? We can't foresee all possible scenarios, so why close the hierarchy for modifications? Also, it is not really sealed if it can be unsealed, so what's the point?
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.
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
I wish you were my teacher 25 years ago in uni
What is your favorite presentations software?
Everyone: MS PowerPoint, Google Slides, etc.
Dr. Venkat: Vim, take it or leave it.
😄😄😄😄
I love it. Text based formats rule. Everyone can read and work with them. *forever!* And they don't endanger your computer.
Excellent explanation Venkat, thanks
Glad you liked it
14:30 I think the main issue is that you're trying to access RedLight (which is package-protected in the package `tl`) from the default package.
This would be an interesting mechanism in multiple development team env. Senior architect can define a certain set of classes to be must extended but extended only once. Plus you can permit who can extend. Utilizing this in designs would be something to keep in mind.
23:19 Initially was wondering how could be dated 01/19/2009, later realized that's from the background wallpaper.
what editor are you using ?
Thanks you a lot
Great video, and my opinion is sealed 😅
am i wrong in think that sealed models can be a way to get rid of unchecked cast in generics?
Could be in some cases... any example in mind?
Let's suppose Java Seals List Interface only for Lists defined by java then i will not be able to extend List to create my own definition rt ?
Open for extension and closed for modification => now Sealed for modification.
Hopping all these are happening for good and for reducing the runtime / unexpected errors we get.
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.
from where Sealed come from?!
explain to me like i'm 5, what problem does it solve? We can't foresee all possible scenarios, so why close the hierarchy for modifications? Also, it is not really sealed if it can be unsealed, so what's the point?
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.
This feature doesn't make much sense by itself. The purpose is more to support the new pattern matching stuff.