• Post Reply Bookmark Topic Watch Topic
  • New Topic

Can you explain the fact?  RSS feed

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why System class in java is final? You might be thinking of to stop sub-classing but actually System class contains private constructor which already stopping other classes to extends system class so why Final for System class?
 
Author and ninkuma
Marshal
Posts: 66307
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's a question for you to answer: why should it not be final?
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's marked final to make it clear that it is designed not to be subclassed. The private constructor prevents us from subclassing it, but that's a side effect of making it private. It's not the reason for doing so.

The correct way to prevent a class from being subclassed is to declare it final. That works for all classes, regardless of whether they have private constructors or not.
 
Marshal
Posts: 56610
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch

If you subclass a class, you do that so you can create instances of both the class and of the subclass. (And that works even if the superclass is abstract.) The System class is uninstantiable, so you cannot create subclass instances. You can therefore not extend from System.
You will find the same applies to most utility classes.
 
Sunit Kumar
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:Here's a question for you to answer: why should it not be final?



In my perspective, if we remove final it does make any difference because its private constructor would not allow to any other class to extend it.
 
Sunit Kumar
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Welcome to the Ranch

If you subclass a class, you do that so you can create instances of both the class and of the subclass. (And that works even if the superclass is abstract.) The System class is uninstantiable, so you cannot create subclass instances. You can therefore not extend from System.
You will find the same applies to most utility classes.


But private constructor is taking care all of that so why Java API developer put extra keyword "final".
 
Ranch Hand
Posts: 172
Java MySQL Database Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A point to note here, Constructors are not inherited. So even if the constructor was marked public or any other access modifier it would not have made any difference.
Therefore, i guess it was simply a design choice of marking the constructor private and marking the class as final so that it cannot be instantiated or subclassed.
 
Ranch Hand
Posts: 228
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think subclassing can allow methods of superclass to be overriden and change. But then it again comes to campbell's point that we cannot instantitate that class.
 
Campbell Ritchie
Marshal
Posts: 56610
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe, the reason for marking it final is to make it obvious to all users that one cannot extend from that class. I agree with Sunit Kumar that you can get the same effect by making all constructors private, but one can find final in the API documentation and one cannot see a private constructor, so maybe it is a point of courtesy.
 
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think Jeff's point is the most applicable. A private constructor means an instance of the class can't be created outside the class declaration. The final keyword means that the class can't be subclassed. If you don't want the class subclassed then make the class final.

The private constructor does NOT replace the final keyword. Take this code:
In this case I want to control the creation of the System instances ... I have a singleton but maybe you have an instance counter or some DB work to get done, or whatever. But you either need to control the instances, provide data others don't have access to or (like in java.lang.System) simply don't have a reason for an instance.

But then a second coder comes, months or years later, and works on the System class. He does this:
System is a non-final class which has a private constructor, but lo: a static inner class can subclass it. Make System final and that is impossible. The second programmer inherited the code, and because the class isn't final he gets no indication that the class should be protected from subclassing. So without further ado, he creates an inner class to get around the private constructor. What is worse is that this would work as well:
Now I have a means of creating new Systems (by System = new System.InSystem() instances) willy-nilly, by-passing the instance controls. Any reason I had for making the private constructor is lost, as would be the design intent of protecting the class from being subclassed. All I have to do to protect from that is make System final. Then none of the problems that the well-intentioned but uninformed second programmer inserted would work. And more importantly the second programmer knows the intent was to keep System from being subclassed, not just to keep instances of it from being created.
 
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sunit Kumar wrote:In my perspective, if we remove final it does make any difference because its private constructor would not allow to any other class to extend it.

I think Campbell's explained why you do it for documentation purposes.

Also: final is a design decision.

Personally, I put it on ALL my classes, because I come from the Paranoid School of Programming.
Simply put: I don't want anyone extending my classes unless I decide they can.

You can always remove it later on if you find it too restrictive; but you cannot add it.

A good example is BigInteger, which (along with BigDecimal) Josh Bloch - who wrote them - freely admits should have been final from the get go. Unfortunately, by the time he worked it out, it was too late.

Winston
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sunit Kumar wrote:
Bear Bibeault wrote:Here's a question for you to answer: why should it not be final?



In my perspective, if we remove final it does make any difference because its private constructor would not allow to any other class to extend it.


That doesn't answer the question. Bear is asking what the benefit would be to making in not final.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sunit Kumar wrote:
Campbell Ritchie wrote:Welcome to the Ranch

If you subclass a class, you do that so you can create instances of both the class and of the subclass. (And that works even if the superclass is abstract.) The System class is uninstantiable, so you cannot create subclass instances. You can therefore not extend from System.
You will find the same applies to most utility classes.


But private constructor is taking care all of that so why Java API developer put extra keyword "final".


I already answered that. And Steve elaborated with a nice example.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ashish Dutt wrote:A point to note here, Constructors are not inherited.


That's not relevant.

 
Sunit Kumar
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Steve Luke wrote:I think Jeff's point is the most applicable. A private constructor means an instance of the class can't be created outside the class declaration. The final keyword means that the class can't be subclassed. If you don't want the class subclassed then make the class final.

The private constructor does NOT replace the final keyword. Take this code:
In this case I want to control the creation of the System instances ... I have a singleton but maybe you have an instance counter or some DB work to get done, or whatever. But you either need to control the instances, provide data others don't have access to or (like in java.lang.System) simply don't have a reason for an instance.

But then a second coder comes, months or years later, and works on the System class. He does this:
System is a non-final class which has a private constructor, but lo: a static inner class can subclass it. Make System final and that is impossible. The second programmer inherited the code, and because the class isn't final he gets no indication that the class should be protected from subclassing. So without further ado, he creates an inner class to get around the private constructor. What is worse is that this would work as well:
Now I have a means of creating new Systems (by System = new System.InSystem() instances) willy-nilly, by-passing the instance controls. Any reason I had for making the private constructor is lost, as would be the design intent of protecting the class from being subclassed. All I have to do to protect from that is make System final. Then none of the problems that the well-intentioned but uninformed second programmer inserted would work. And more importantly the second programmer knows the intent was to keep System from being subclassed, not just to keep instances of it from being created.





So impressive explanation !!! Thank you so much.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sunit Kumar wrote:So impressive explanation !!! Thank you so much.

It's nice that you're thanking people; but just for the future: You don't need to quote the entire post in your response. A line or two is usually enough.

Winston
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!