This week's book giveaway is in the Cloud/Virtualization forum.
We're giving away four copies of Learning OpenStack Networking: Build a solid foundation in virtual networking technologies for OpenStack-based clouds and have James Denton on-line!
See this thread for details.
Win a copy of Learning OpenStack Networking: Build a solid foundation in virtual networking technologies for OpenStack-based clouds this week in the Cloud/Virtualization forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

Why the class Class is final and cannot be extended?  RSS feed

 
Ranch Foreman
Posts: 127
5
BSD Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As in subject , any clue about what's the reason to make unextensible that class?

from the API

Class has no public constructor.Instead Class objects are constructed automatically by the Java Virtual Machine as classes are loaded and by calls to the defineClass method in the class loader.


 
Author and ninkuma
Marshal
Posts: 66797
168
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What utility would there be in extending the Class class?
 
Harry Kar
Ranch Foreman
Posts: 127
5
BSD Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Bear Bibeault wrote:What utility would there be in extending the Class class?


Hi Bear
 
Dunno maybe for the IDE's designer. I was interested in what's the rationale behind that decision  from the Sun's part 
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66797
168
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Exactly what I asked. If there's no utility in extending a class, why not make it final?

In fact, there are many who would say that all classes not intentionally meant to be extended should be declared as final.

So you need to find a reason for it not for it to be final rather than tryinfg to find a reason that it was made final.
 
Sheriff
Posts: 23692
50
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Seems to me that you might be able to create a lot of havoc by extending java.lang.Class and then persuading user code to use your extension. Language designers don't like havoc being created like that, it makes it hard to design a language which works in a rational and predictable way.
 
Harry Kar
Ranch Foreman
Posts: 127
5
BSD Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Bear Bibeault wrote:Exactly what I asked. If there's no utility in extending a class, why not make it final?



For a class designer have to be hard. How he can predict a priori every possible future use and be right?

In fact, there are many who would say that all classes not intentionally meant to be extended should be declared as final.



That seems to me a good strategy if a priori the class designer is pretty sure(have examined all possible future uses but is that possible?) about the non extensibility of his class

So you need to find a reason for it not for it to be final rather than tryinfg to find a reason that it was made final.


For my question either point of view fits well. I' m curious in what has passed in head of class's Class designer to make it not extensible? that's not casual i guess he tried to protect something but what precisely?
 
Sheriff
Posts: 12318
200
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Harry Kar wrote:Dunno maybe for the IDE's designer. I was interested in what's the rationale behind that decision from the Sun's part


Not to pile on to what's already been pointed out but I don't see how an IDE's design even comes into play here. An IDE's design is entirely irrelevant when it comes to deciding the design of a class like java.lang.Class. You probably meant to say "the Java Language designers", right?

java.lang.Class is a very meta-type class: it's a class that allows you to deal with the concept of a Java "class" and data and behavior associated with that concept. The concept of a "class" in Java is fundamental to the object-oriented nature of the language. As such, it's difficult to imagine why you would want to extend java.lang.Class.

This, of course, leads us back to the question Bear asked which is "Why do you think it might be useful to extend java.lang.Class?" Did you have a specific scenario in mind or was that really just a rhetorical question in the same class as questions like "Why did the universe decide to make the sky blue instead of purple?"?

*Note: Whenever someone says "Not to (whatever) but ...," that usually means they actually are going to say something that is exactly what that "whatever" is. (shrug)
 
Harry Kar
Ranch Foreman
Posts: 127
5
BSD Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Paul Clapham wrote:Seems to me that you might be able to create a lot of havoc by extending java.lang.Class ...



Hi Paul
I have the same suspect(but  have no idea on how) can you extend your thought about the probable  havoc ?
 
Harry Kar
Ranch Foreman
Posts: 127
5
BSD Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:

Harry Kar wrote:Dunno maybe for the IDE's designer. I was interested in what's the rationale behind that decision from the Sun's part


Not to pile on to what's already been pointed out but I don't see how an IDE's design even comes into play here. An IDE's design is entirely irrelevant when it comes to deciding the design of a class like java.lang.Class. You probably meant to say "the Java Language designers", right?



Hi Junilu
Yes i repond tp  Bear that a possible user of Class class may be an IDE's designer or dunno where elsewhere can be used that class

java.lang.Class is a very meta-type class: it's a class that allows you to deal with the concept of a Java "class" and data and behavior associated with that concept. The concept of a "class" in Java is fundamental to the object-oriented nature of the language. As such, it's difficult to imagine why you would want to extend java.lang.Class.

This, of course, leads us back to the question Bear asked which is "Why do you think it might be useful to extend java.lang.Class?" Did you have a specific scenario in mind or was that really just a rhetorical question in the same class as questions like "Why did the universe decide to make the sky blue instead of purple?"?)



No i haven't a specific scenario in mind and i wonder (that's the reason i put the question) but on the other hand it's not a rhetorical question too if behind that decision i guess is "hiding" precise arguments
I talk about the language designer point of view  not the user of the language point of view
 
Junilu Lacar
Sheriff
Posts: 12318
200
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, the only "precise" argument I can think of is that it doesn't make sense to allow java.lang.Class to be extended, so let's just make it final. I believe that's all there really is to it and that there are no other "hidden" agenda as you may have been wondering.
 
Junilu Lacar
Sheriff
Posts: 12318
200
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Were you perhaps wondering whether the reason for making java.lang.Class final was the same kind of reason that classes like java.lang.Math was made final? In that particular class, the answer would be "No, the reasons for making each of these classes final are probably different." java.lang.Math is really just a container for static utility methods which is why we often call it a "utility" class. As such, there's really no need to create instances of java.lang.Math because an instance would have no unique capability or attribute. There's nothing that would distinguish the behavior of one Math object from another Math object. Thus, the java.lang.Math class was designed in such a way that you can't actually create instances of it. That is, the Math class has a private constructor, thus making it impossible to create instances of the class from outside of the Math class itself. Additionally, to make sure the intent of the design was clear, the java.lang.Math class was made final so that it would be impossible to create a subclass of it that you could instantiate.

That is different from java.lang.Class, which you definitely would want to create instances of because each instance will define a specific class and there are an infinite number of possibles classes in the Java universe.
 
Saloon Keeper
Posts: 9217
177
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Harry, I like that you wondered whether the designer considered all use cases ahead of time. They probably didn't, and that's exactly the reason why the class was made final.

It's incredibly difficult to write a class that is fit for inheritance. Especially when you allow other people to extend your classes do you need to consider lots of use cases and reasons why they might want to extend your class. This is time consuming and error prone work. If you make a class final, you protect yourself against a lot of headache. If a class is final, you can always make it non-final in a next release. Once your class is non-final, you can never go back, because people who have written a subclass will have their code break. This is the reason why so many people are saying to make all your classes final as a matter of habit, and only make them non-final after you've thought very long and very hard.

A nice benefit is that if you make your class final, and a large group of people complain about it, the onus is on them to come up with valid use cases.
 
Stephan van Hulst
Saloon Keeper
Posts: 9217
177
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here are a couple of things to consider when you make your class extensible:

  • Do your constructors call overridable methods? (They mustn't.)
  • Do all your method contracts explicitly state what overridable methods they call? (If you override the dependent methods, behavior of other methods might change.)
  • Do all your overridable methods document their default implementation? (Subclasses need to know what behavior they will be overriding.)
  • Do you override the equals() and hashCode() methods? (Once you override these methods, they must be made final and subclasses may not override them.)
  • Do you implement clone()? (Even if your base class is not Cloneable, a subclass might be.)

  • Finally, there is the difficult question of what parts of your class' internals you need to expose, i.e. making members protected when they could have been private instead. For instance, AbstractList exposes the field modCount, which in a final class would have been private.

    As you can see, these are already lots of things to consider, and that's just off the top of my head. I haven't mentioned what things you might need to consider when your class needs to take things like serialization and concurrency into account.
     
    Harry Kar
    Ranch Foreman
    Posts: 127
    5
    BSD Eclipse IDE Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    As Junilu remarked

    java.lang.Class is a very meta-type class: it's a class that allows you to deal with the concept of a Java "class" and data and behavior associated with that concept. The concept of a "class" in Java is fundamental to the object-oriented nature of the language. ...


    and Paul too

    Seems to me that you might be able to create a lot of havoc by extending java.lang.Class ...



    Probably all  that has to do with type safety and  all we know that Java is a strongly typed language  and permits no one to change that
    All start from static and dynamic binding. The flexibility given  by subtype polymorphism makes the declared (static) type of an object in general different from its run-time (dynamic) type.
    The run-time type is in general a subtype of the static type.
    e,g.

    The static type of a is AClass and after the assignment a=b its runtime type is AsubClass. This has implications on selection of the most appropriate method when executing a message.

    In order for overriding to work correctly the method to be invoked is determined by the dynamic type of the receiver object (also known as  dynamic dispatch (selection) of methods and is the most important case of dynamic binding in OO languages.)
    e.g.

    The method to be invoked in response to the message a.equals(b) will be the method equals overridden in the class Vehicle because the run time type of a is Vehicle.

    There are situations in which overriding a method might be problematic  and should not be allowed. A good example is the Java.lang.Object 's  getClass() . The invocation of this method will return the class object of the receiver of the method. Allowing overriding would have serious implications on the intended semantics of this method creating nontrivial problems in dynamic type checking. This is probably why the getClass() is declared as final.


    The class Class is final, i.e. cannot be extended, and hence none of its methods can be overridden. Since the class Class has only introspection methods, this guarantees safety of the type system at run-time, i.e., the type information cannot be mutated at run time.





     
    Harry Kar
    Ranch Foreman
    Posts: 127
    5
    BSD Eclipse IDE Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Obviously that's a supposition (that seems to me fits well in some extend) If there are other plausible reasons i was glad to here about   
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!