• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Can you explain the fact?

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Python MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 79177
377
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Wait for it ... wait .... wait .... NOW! Pafiffle! A perfect tiny ad!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic