Overloading return values
I will start this post talking about
StringBuffer and StringBuilder. As some might know, Java 5.0 added the new StringBuilder class with the same interface as StringBuffer's.
I can only rant about the name choice: If Sun really wanted the StringBuilder to only serve as an unsynchornized version of StringBuilder, maybe they should have used the same pattern they had with synchronized collections and maps, with a method like StringBuffer.unsynchronized(StringBuffer) or something similar, much like Collections.synchronizedList(List). These two classes don't even implement the same interface. It seems like the only reason for this weird naming is to make it easier to find for people who've seen the same class in dotNet. But maybe that's just my feeling.
Okay, enough rant. While looking at the classes, I noticed they implement Appendable, which provides methods such as Appendable Appendable.append(char). However, StringBuffer provides a method StringBuffer StringBuffer.append(char), and has no other method returning Appendable.
Now, maybe I'm just finding out something very old here, but I made a small test and wrote the following:
public interface a {
a doSomething();
}
public class b implements a {
b doSomething();
}
Not being able to become surprised by now, it compiled successfully. A short look using javap revealed:
l~/test $ javap code.a
Compiled from "a.java"
public interface code.a{
public abstract code.a doSomething();
}
l~/test $ javap code.b
Compiled from "b.java"
public class code.b extends java.lang.Object implements code.a{
public code.b();
public code.b doSomething();
public code.a doSomething();
}
Apparently, the bytecode contains an overload which differentiates by return value only! Obviously, doing such a thing manually would cause a compilation error. I wonder how far back this feature went? I think it's new.. But don't have the time to start searching for something written about it.
Comments (7)