Jump to content

  • Log In with Google      Sign In   
  • Create Account

[JAVA] What if I don't define the toString() method?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 Shaquil   Members   -  Reputation: 819

Like
0Likes
Like

Posted 24 May 2013 - 06:17 AM

I'm going through a Java book, and the author mentioned that anytime I try to convert an object to a string, the compiler will call that object's toString() method. Example:

 

 

ExampleObject A = new ExampleObject();//toString() is not overridden in the class definition

System.out.println("to String = " + A);//What is going to happen now?
 

 

 

Although in his example, he did override the toString() method in his class, he never says what'll happen if I don't do that. Looking online a bit, I couldn't find an answer, but it is clear that even if toString() is not overridden it will be called, will return a string, and the compiler won't yell at me. So what exactly is going on? Also, could anyone explain why in god's name this was a good idea to build into the language?


Edited by Shaquil, 24 May 2013 - 06:17 AM.


Sponsor:

#2 Andy474   Members   -  Reputation: 685

Like
0Likes
Like

Posted 24 May 2013 - 07:01 AM

im not sure about java, but in C# it would be printed like this:

 

(assume your example class is in the namespace MyObjects.Classes)

"to String = MyObjects.Classes.ExampleObject"

I assume something similar will happen, either way, it will not cause your program to crash or cause something to catch fire :)


Edited by Andy474, 24 May 2013 - 07:02 AM.


#3 Wooh   Members   -  Reputation: 627

Like
4Likes
Like

Posted 24 May 2013 - 07:13 AM

If you don't define toString() it will be inherited from Object, that defines it as
getClass().getName() + '@' + Integer.toHexString(hashCode())


#4 Shaquil   Members   -  Reputation: 819

Like
0Likes
Like

Posted 24 May 2013 - 07:28 AM

If you don't define toString() it will be inherited from Object, that defines it as

getClass().getName() + '@' + Integer.toHexString(hashCode())

 

 

That's more along the lines of what I was looking for, thanks. By the way, is that Integer.toHexString(hashCode()) supposed to be the object's location in the heap?

 

Andy747 mentioned that it saves your program from crashing, but shouldn't that be a compile-time error anyway? If I'm trying to convert an object to a string, and toString() isn't explicitly overridden, doesn't that imply that I made a typo, and I don't actually want to convert the object itself into a string?

 

I'm sure there's a good reason why it does this, so that's why I'm asking.


Edited by Shaquil, 24 May 2013 - 07:30 AM.


#5 WavyVirus   Members   -  Reputation: 735

Like
1Likes
Like

Posted 24 May 2013 - 07:30 AM

Why might toString be a good idea?

* Getting a textual representation of an object is a super common task. When logging debug information, for example.

* As every class derives from Object, there is a sensible place to define the toString method

* There is a sensible default which can be applied when the programmer doesn't specify their own toString

* Guaranteeing that all objects have some kind of string representation allows us to do things like printing a list of all objects in a collection without worrying about the specific object types involved

#6 TheChubu   Crossbones+   -  Reputation: 4420

Like
0Likes
Like

Posted 24 May 2013 - 07:43 AM

I'm sure there's a good reason why it does this, so that's why I'm asking.

Because Java has string concatenation in a very special place, his heart, its a magical place where overrideable operators live and thrive! So it can do very special things in there, like the one you described.


"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

 

My journals: dustArtemis ECS framework and Making a Terrain Generator


#7 Wooh   Members   -  Reputation: 627

Like
0Likes
Like

Posted 24 May 2013 - 08:40 AM

By the way, is that Integer.toHexString(hashCode()) supposed to be the object's location in the heap?

No. Hash codes are normally meant to be used in hash tables and things like that. The hashCode() defined by Object might very well use the memory address but it's not guaranteed, and many classes overrides this method to return the same hash code for all objects that compares equal.

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)



#8 return0   Members   -  Reputation: 444

Like
0Likes
Like

Posted 25 May 2013 - 04:51 AM

A hash code should be immutable and deterministic so is unlikely to be based on memory address?

#9 Aldacron   GDNet+   -  Reputation: 3191

Like
0Likes
Like

Posted 25 May 2013 - 07:28 AM

A hash code should be immutable and deterministic so is unlikely to be based on memory address?

 

In the Sun/Oracle implementation, it's not actually the memory address used by default, but rather a value based on the object's reference (the reference value is not necessarily the same as the memory address, but could be). This is all implementation dependent and there are no guarantees that's what will be used. So it's not something to be relied on. What can be relied on is that a default hashcode implementation exists for every object that will allow the object to be stored in hashmaps and such.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS