I know that when final keyword is used before a Class , the Class cannot be inherited by another Class.
But I have never seen its real usage in Java Coding except for immutable classes.
In which scenarios it will be really required to use final keyword before a Class?
And does not it reduce the reusability feature of Java language?
A final class cannot be subclassed. This is done for reasons of security and efficiency. Some of the classes in Java API are final, for example java.lang.System. Sometimes security and immutability is of far more importance than re usability.
According to this IBM developerWorks article :
The common perception is that declaring classes or methods final makes it easier for the compiler to inline method calls, but this perception is incorrect (or at the very least, greatly overstated).
final classes and methods can be a significant inconvenience when programming -- they limit your options for reusing existing code and extending the functionality of existing classes. While sometimes a class is made final for a good reason, such as to enforce immutability, the benefits of using final should outweigh the inconvenience. Performance enhancement is almost always a bad reason to compromise good object-oriented design principles, and when the performance enhancement is small or nonexistent, this is a bad trade-off indeed.
Also read this Open Closed Principle:
Software Entities (Classes, Modules, Functions, etc.) should be open for Extension, but closed for Modification.
final class can not be inherited. So if you want that nobody can inherit your class then you can declare it as final. So you have already answers your own questions. So main usage are
Both are them are used for security reasons. To protect your system to be changed by using your critical classes. Is not it enough for being a reason?
final keyword can be used with a class in order to provide security. We can take the example of String. String class was made immutable as well as final to enhance security of file handling in java.
Though, performance is also a reason (assuming you are already aware of the internal String pool maintained for making sure that the same String object is used more than once without having to create/re-claim it those many times), but the main reason why String has been made immutable in Java is 'Security'. Surprised? Let's understand why.
Suppose you need to open a secure file which requires the users to authenticate themselves. Let's say there are two users named 'user1' and 'user2' and they have their own password files 'password1' and 'password2', respectively. Obviously 'user2' should not have access to 'password1' file.
As we know the filenames in Java are specified by using Strings. Even if you create a 'File' object, you pass the name of the file as a String only and that String is maintained inside the File object as one of its members.
Had String been mutable, 'user1' could have logged into using his credentials and then somehow could have managed to change the name of his password filename (a String object) from 'password1' to 'password2' before JVM actually places the native OS system call to open the file. This would have allowed 'user1' to open user2's password file. Understandably it would have resulted into a big security flaw in Java. I understand there are so many 'could have's here, but you would certainly agree that it would have opened a door to allow developers messing up the security of many resources either intentionally or un-intentionally.
With Strings being immutable, JVM can be sure that the filename instance member of the corresponding File object would keep pointing to same unchanged "filename" String object. The 'filename' instance member being a 'final' in the File class can anyway not be modified to point to any other String object specifying any other file than the intended one (i.e., the one which was used to create the File object).
I research this, and I read this on Hardcore Java, Publisher : O'Reilly ISBN : 0-596-00568-7
Why Classes are tagged Final:
There are two ways to make a class final. The first is to use the keyword final in the class declaration:
public final class SomeClass {
// . . . Class contents
}
The second way to make a class final is to declare all of its constructors as private:
public class SomeClass {
public final static SOME_INSTANCE = new SomeClass(5);
private SomeClass(final int value) {
}
Marking it final saves you the trouble if finding out that it is actual a final, to demonstrate look at this Test class. looks public at first glance.
public class Test{
private Test(Class beanClass, Class stopClass, int flags)
throws Exception{
// . . . snip . . .
}
}
Unfortunately, since the only constructor of the class is private, it is impossible to extend this class. In the case of the Test class, there is no reason that the class should be final. The Test class is a good example of how implicit final classes can cause problems.
So you should mark it final when you implicitly make a class final by making it's constructor private.
A final class cannot be subclassed. This is necessary to improve security even if it has some drawbacks.
E.g. the class java.lang.String is final. Therefore you cannot subclass String and can be sure that a String parameter is never a subclass that does something harmful (e.g. sending the String somewhere).
