For further actions, you may consider blocking this person and/or reporting abuse
Read next
Data API for Amazon Aurora Serverless v2 with AWS SDK for Java - Part 10 Aurora Serverless v2 Data API meets DevOps Guru or not?
Vadym Kazulkin -
Create an AWS SNS Topic Using CDK and consume messages with a Spring Boot Microservice
Kevin Lactio Kemta -
How to Remove Class Symbols (Green Circles) from the Eclipse Package Explorer
JavaFullStackDev.in -
Top Interview questions for DevOps Part-3
Avesh -
Top comments (9)
The final keyword in Java means: „can‘t be modified“. Applied to a field/variable it means: it‘s a constant (the value can’t be modified.) Applied to a class, it means: class can’t be extended (and thus, modified).
To be more correct: the variable assignment cannot be modified. Only in case of primitives and immutable objects the value cannot be modified.
Thanks, @bertilmuth .
As you said final keyword in java means "can‘t be modified", but still we should be allowed to extend it from another class so that we can use its defined method.
I totally agree that if we try to modify any of its methods then it should give an error, but otherwise we should be allowed to extend that final class and reuse its method in another class.
Please correct me if I am wrong anywhere.
As Kasey Speakman has pointed out, you can extend final classes by composition. Just not inheritance. A class can offer all visible methods of the final class, plus further methods.
The creator of the class explicitly marked it that way because they did not want you to extend it. Probably to avoid having access to its protected members. But I can only guess as to their intentions. Generally, you have to use such a class with composition (create one and put it in a private field in your own class) rather than inheritance.
First of all, a final class can make sense. Imagine what would happen if somebody were to extend String, Integer or any of the other builtin classes - the JVM would be unable to perform a lot of optimizations. Sometimes, the programmer just didn't want to allow inheritance for architectural reasons. Granted, it's a rare occasion, but the possibility is there if you need it.
WARNING: VERY ADVANCED STUFF AHEAD
That being said, there actually is a possibility to inherit from a final class. This is needed mostly for internal purposes in frameworks like Spring of Hibernate. Using reflection, the final modifier of a class can be disabled at runtime, and the byte code of a class can be generated which extends the formerly final class. Don't try this at home.
The
final
keyword is much more related to the intent behind that class than any physical restriction from Java or the JVM. As others have mentioned, it is technically possible to extend a final class, but it is difficult and dangerous to do so.In Java, a final class is an opt-in feature, meaning the developer chose to make this class final. They looked at the class and the way it is intended to be used, and decided it makes more sense for it to not be extended. There are several reasons why they might have made this choice:
Fragment
instance, but our application logic requires an instance ofFragmentProvider
(a custom class), notFragment
. ThisFragmentProvider
class is final, and contains methods for loading/unloading fragments and tying them into our custom application lifecycle, which is functionality built on top of the normal ViewPager. Our ViewPager adapter only accepts a list ofFragmentProvider
as input, so there is only one way to add a new Fragment to do it, and that one way is perfectly in-line with the original developer's intention.Context
base class in Android is a god-class that knows entirely too much, and is fragmented across many different implementations through a deep and confusing hierarchy. AnApplication
is aContext
. AnActivity
is aContextThemeWrapper
which is aContextWrapper
which is aContext
. And supporting older versions of android, anAppCompatActivity
has 9 extended classes before reachingContext
. This makes it confusing to reason about which code is actually being run, and in what order, and it would have probably been a better idea to have made just a fewContext
-type classes (just Context, Application, and Activity) and have the rest of the needed behavior implemented through composition.I wrote a post with code examples that will hopefully explain this a bit more concretely.
Because it's final.
Use composition instead of inheritance if you want to "extend" a final class.
See the Decorator Pattern