Hello people,
I am curious to know why the root class OBJECT, empty class, is a class why it was not created as an interface? What difference would make if it were an interface?
I would appreciate and reward points for good reasons.
Thanks & Regards,
Anand Patil :)
> I am curious to know why the root class OBJECT, empty
> class,
Maybe you should read the Javadocs or look at the sources if you haven't yet seen that it's all but empty?
> is a class why it was not created as an
> interface? What difference would make if it were an
> interface?
Moot point. Object is a non-empty, non-abstract class.
Actually Object is a nonempty .
Eg:
I passed one integer var to a method as an argument.
Integer a;
add(a);
In the called method you can define like that Object a,ie
add(Object aValue)
you can get the value of a like this way
Integer bValue=(Intger)aValue
If it is an Interface u cannt do like this.
this is one of the smallest example that I can provide .
> Actually Object is a nonempty .
I already said that.
> I passed one integer var to a method as an argument.
>
> Integer a;
>
>
>add(a);
> In the called method you can define like that Object
> a,ie
>
>add(Object aValue)
> can get the value of a like this way
So what does any of this have to do with Object being an interface or not?
> Integer bValue=(Intger)aValue
>
> If it is an Interface u cannt do like this.
[ _ ] You have any idea what you're taliking about.
Serializable s = (Serializable) aValue;
With aValue being an Integer, it works perfectly.
> this is one of the smallest example that I can provide .
It's also one of the wrongest ones.
And in that example you are not truely using Object in any way shape or form. Using Object as the Parameter type in a method declaration (i.e. add(Object a)), simply means that it can be fed any "Object" as an argument since Object is the base class for everything.
Edit: And I am a day late and dollar short.
> I am curious to know why the root class OBJECT, empty
> class, is a class why it was not created as an
> interface? What difference would make if it were an
> interface?
IMHO, all Java objects must have some general-purpose methods like equals(), toString(), and hashCode(). Therefore they are implemented in the Object class, which is the superclass of all other classes. While some of these methods are overridden in subclasses, others e.g. hashCode() are not for obvious reasons.
Message was edited by: java_knight
> others e.g. hashCode() are not for obvious reasons.
Which obvious reasons would that be? If you override equals() you have to override hashcode() too.
> Which obvious reasons would that be? If you override
> equals() you have to override hashcode() too.
Please correct me if I'm wrong, but you can stick with the original implementation of hashCode() - which provides a hash code value for the object. Reimplementing it would be a pain. On the other hand, providing a custom equals() method for your custom object is often a good idea.
This whole thread is nonsense. java.lang.Object isn't an "empty" class, and there are some final methods in the class that have to be implemented here. Hence, no interface. Can you imagine if we were allowed to provide our own implementation of wait et al?
> java.lang.Object isn't
> an "empty" class, and there are some final methods in
> the class that have to be implemented here.
> Hence, no interface.
That was exactly my point. Can you imagine having to implement hashCode() each time?
Message was edited by: java_knight
> > Which obvious reasons would that be? If you
> override
> > equals() you have to override hashcode() too.
>
> Please correct me if I'm wrong, but you can stick
> with the original implementation of hashCode() -
> which provides a hash code value for the object.
> Reimplementing it would be a pain. On the other hand,
> providing a custom equals() method for your custom
> object is often a good idea.
Equal objects have to return equal hashcodes by contract. So any change to equal()'s implementation (which returns true only on referential identity) needs a change in hashCode() (which returns unique numbers) as well.
Look at the API docs for Object.hashCode().
> Can you imagine if we were
> allowed to provide our own implementation of wait et
> al?
Can you imagine if we are *forced* to provide our own implementations? Because that's what the interface does...
> Equal objects have to return equal hashcodes by
> contract. So any change to equal()'s implementation
> (which returns true only on referential identity)
> needs a change in hashCode() (which returns unique
> numbers) as well.
>
> Look at the API docs for Object.hashCode().
Sometimes I override equals() for my homemade classes but I never override hashCode(). I've seen most programmers do this. Is this a programming mistake or just a glitch (e.g. override of hashCode() is necessary only when using hashtables)?
> Sometimes I override equals() for my homemade classes
> but I never override hashCode(). I've seen most
> programmers do this. Is this a programming mistake or
> just a glitch (e.g. override of hashCode() is
> necessary only when using hashtables)?
http://www-106.ibm.com/developerworks/java/library/j-jtp05273.html
http://java.sun.com/developer/Books/effectivejava/Chapter3.pdf
~
> > java.lang.Object isn't
> > an "empty" class, and there are some final methods
> in
> > the class that have to be implemented here.
> > Hence, no interface.
>
> That was exactly my point. Can you imagine having to
> implement hashCode() each time?
>
> Message was edited by: java_knight
Whoah there boy. What's this beef you have with implementing hashCode yourself? You never had to do that? Just wait, you will do.....
> > Equal objects have to return equal hashcodes by
> > contract. So any change to equal()'s
> implementation
> > (which returns true only on referential identity)
> > needs a change in hashCode() (which returns unique
> > numbers) as well.
> >
> > Look at the API docs for Object.hashCode().
>
> Sometimes I override equals() for my homemade classes
> but I never override hashCode(). I've seen most
> programmers do this. Is this a programming mistake or
> just a glitch (e.g. override of hashCode() is
> necessary only when using hashtables)?
Those 2 methods should always be overriden in tandem
yeah i guess that might be one of the reasons why OBJECT is a class and not an interface.
As the superclass of all classes by default provides few methods with definition, which can be overridden (if they are not final) by any means. To get such design would not have been possible if OBJECT were an interface.
Thanks a lot Java_Knight and all others.
Regards,
Anand Patil.
Message was edited by:
Anand_Java
> Sometimes I override equals() for my homemade classes
> but I never override hashCode(). I've seen most
> programmers do this.
Bad bad bad.
> Is this a programming mistake
Yes.
> or
> just a glitch (e.g. override of hashCode() is
> necessary only when using hashtables)?
If you never use it in a hash-based collection, you're probably safe, BUT it's stupid not to override them together. You don't always know what's going to be calling hashCode, and anything that does will assume it's implemented correctly.
equals and hashCode:
http://java.sun.com/developer/Books/effectivejava/Chapter3.pdf
D'oh! I see this reference in reply #13. So, prob solv!
Message was edited by:
BigDaddyLoveHandles
I HAVE LOUD DOUBT... IF NOT INTERFACE THEN Y NOT
MULTIPLE INHERITANCE 4 JAVA... I WANT CLASS TO BE OBJECT
BUT SOMETHING ELSE 2... PLZ
> I HAVE LOUD DOUBT... IF NOT INTERFACE THEN Y NOT
> MULTIPLE INHERITANCE 4 JAVA... I WANT CLASS TO BE
> OBJECT
> BUT SOMETHING ELSE 2... PLZ
import java.awt.*;
import java.awt.event.*;
public class TryThis {
public static void main(String[] args) {
Toolkit.getDefaultToolkit().setLockingKeyState(KeyEvent.VK_CAPS_LOCK, false);
}
}
> public class TryThis {
>public static void main(String[] args) {
>
> oolkit.getDefaultToolkit().setLockingKeyState(KeyEvent
> .VK_CAPS_LOCK, false);
>}
I HAVE DOUBT... HOW MY CLASS USE UR CODES AND BE
OBJECT... BCZ JAVA IS ONLY SINGLE INHERITANCE...
YOU DONT KNOW... PLZ ONLY ANSWER WITH SERIOUS DOUBT KILLERS!!!... YOU BAD MAN...
> > I HAVE LOUD DOUBT... IF NOT INTERFACE THEN Y NOT
> > MULTIPLE INHERITANCE 4 JAVA... I WANT CLASS TO BE
> > OBJECT
> > BUT SOMETHING ELSE 2... PLZ
> [code]
> import java.awt.*;
> import java.awt.event.*;
>
> public class TryThis {
>public static void main(String[] args) {
>
> oolkit.getDefaultToolkit().setLockingKeyState(KeyEvent
> .VK_CAPS_LOCK, false);
>}
> /code]
"But how would I do it in Eclipse?"
>> "But how would I do it in Eclipse?"
with a series of overly complicated maneuvers through
various 3rd party plugins within a snail paced gui and without
any RAM to spare.
> >> "But how would I do it in Eclipse?"
>
> with a series of overly complicated maneuvers
> through
> various 3rd party plugins within a snail paced gui
> and without
> any RAM to spare.
Indeed. Workaround nailed onto workaround nailed onto workaround, so the whole thing "works" as long as it's Tuesday, but not the third Tuesday of an odd-numered month, and you're stood on one leg, wearing blue socks. But not dark blue socks
