Overloading in java

Should be two fold
First it would be very inefficient interms of compiler optimisation.
The second and the key point is , if the reurn value is differennt then you are not really overloading.
Overloading is achieving the same result from different starting conditions.

So while it could be achieved it would be messy or slow, or possibly both. On top of the it would confuse the heck out of anyone trying to use the code. There's enough of that sort of thing about already.

If you want a different return type from two methods that do the 'same thing' then they don't do the same thing.

You could have 'trivial' differences such as byte or integer, or even signed and unsigned, but I personally would be revisiting my design if I got to that point.

That sort of trivial difference can give you serious run time errors which would be very difficult to debug.

Interpreted literally your question means that you would like to have different methods called when the return type of a method is changed (a class could have method "Float something ()" and "Boolean something ()" and each one would be a different method). I am not sure that's what you want. Anyway starting with Java 1.5 this would now be impossible. Because to implement the generics Java 1.5 supports Covariant Return Type. Using this an overriding method can change the return type to any subtype of the original type (the get(..) of a collection can now return different specific type.

There is probably no good reason why the return type is not considered in overloading methods. It could probably used to force the return a value in different, yet similar data types, such as string or stringbuffer. I would argue, however, that this is not an important issue as I would recommend avoiding use of overloading.

I came to this conclusion back in my early C++ days because I found that when I was using overloading it was for one of two reasons. Either I was actually writing two different functions or I was writing a single function but performing data type conversion. In the first case, it adds clarity to give the different functions different names. In the second case, it adds clarity to refactor the program to use a common data type. I found many bloated classes that shrank considerably when not support all possible combinations of call parameter types. I pushed any needed conversions back to the calling code and have discovered that there is usually a very limited number of needed conversions.

In general, avoid overloading. I can't really think of a case where it does not detract from code clarity.

The value is the identified object itself so there is no need to indicate a return value.