• 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:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

java.lang.Object as interface

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't know the right place to put the question but anyway!

My question is what would have been the changes pros or cons IF the java.lang.Object was an interface. The only thing that I can see is the implementation of the methods must have been a must for every class.

More interstingly, What would have been the situation if it was

public class Object implemets ObjectInterface ....

Has there been any cons for inheritance since we are assuming the interface as the "mother" of all objects
 
author and iconoclast
Posts: 24203
43
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Forcing every class to implement half-a-dozen cookie-cutter methods like equals(), hashCode(), and toString() would have without a doubt ensured that Java never became popular. Who would want to write all that boilerplate just to get "Hello, World!" to work!

And of course, some methods like wait() and notify() can't even be implemented without using native methods, so you'd either have to provide an implementation that all classes would be required to forward to.

So you'd have traded the current simple system for a bunch of rules which would have to be enforced by the compiler, and a lot of extra work for the programmer. I can't think of a single advantage to your scheme -- can you?
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Try the following code:



This compiles and runs, although Serializable doesn't declare toString and, of course, doesn't extend Object! There seems to be an implicite interface all interfaces are extending - a small inconsistency in the language, I would say...
 
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator



This compiles and runs, although Serializable doesn't declare toString and, of course, doesn't extend Object! There seems to be an implicite interface all interfaces are extending - a small inconsistency in the language, I would say...


According to JLS, the first statement declares an annonymous class which extends Object and implements Serializable. I don't see any inconsistency here.

[ May 20, 2005: Message edited by: Vlado Zajac ]
[ May 20, 2005: Message edited by: Vlado Zajac ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Vlado Zajac:

According to JLS, the first statement declares an annonymous class which extends Object and implements Serializable. I don't see any inconsistency here.



The anonymous class is not important to my point.

The point is: s is of type Serializable. Serializable doesn't extend any other interface, and of course also doesn't extend Object. That is, the type Serializable doesn't directly or indirectly declare any methods. And still I'm able to call method toString on a variable of that type.
 
Ernest Friedman-Hill
author and iconoclast
Posts: 24203
43
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
<pedantic>

Section 9.2 of the JLS, second edition (emphasis mine)


If an interface has no direct superinterfaces, then the interface implicitly declares a public abstract member method m with signature s, return type r, and throws clause t corresponding to each public instance method m with signature s, return type r, and throws clause t declared in Object, unless a method with the same signature, same return type, and a compatible throws clause is explicitly declared by the interface.



Interesting way to describe what's going on here.

</pedantic>
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Ernest Friedman-Hill:
Section 9.2 of the JLS, second edition (emphasis mine)



I suspected that there must be something in the JLS, but was to lazy to search for it...

Thanks for the quote!


Interesting way to describe what's going on here.



Agreed. In my opinion, it would have been simpler to introduce an interface from which all other interfaces and the Object class inherit. Well, what can you do... :roll:
 
Ernest Friedman-Hill
author and iconoclast
Posts: 24203
43
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
In my opinion, it would have been simpler to introduce an interface from which all other interfaces and the Object class inherit.



I've never tried to write a Java compiler, nor looked closely at the source for one. Since interface class files don't physically include these implicit methods, it seems to me that this kind of special case does indeed have to be built into the compiler. You're right.
 
Why fit in when you were born to stand out? - Seuss. Tiny ad:
professionally read, modify and write PDF files from Java
https://products.aspose.com/pdf/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!