On 03/06/2013 10:31 PM, Rob Cernich wrote:
Also, it's much easier to change from void to some type as nobody
is using the return value already.
It's true that changing from void to some type maintains source
compatability, the issue here is that it breaks binary compatability. So
some tools compiled against jbt 4.0.0 but running in a 4.0.1 environment
(after you changed void to SomeObject) will get exceptions in that the
method is NOT FOUND. This will make our tools useless.
If the method is typed appropriately and that type changes you will
get a compile error. If the return type is Object and you change the
type you will get a ClassCastException.
Changing the return type at all is a binary api breakage. Plain and
simple. Changing it from Object to OtherObject is a breakage. Changing
it from void to SomeObject is a breakage. All of them are breakages. The
only way would be to maintain the method signature at Object, but return
whatever you want, leaving it up to clients to properly cast it. This
is of course ugly, but it's better than binary incompatabilities.
If you're using Object to provide flexibility for extended
interfaces, I suggest parameterizing the type instead,
I'm sure you're right, but if we had the foresight of coding for flexibility
before, we wouldn't have the issue of people changing return types now ;) THe issue
I'm bringing to light is people changing interfaces that were not coded in expectence
of flexibility. In short, you can't. So don't. ;)