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

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 :)

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

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

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.

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

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.

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 Java^TM programming language.)

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

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.