[jbosstools-dev] Migrating API

Rob Stryker rstryker at redhat.com
Wed Mar 6 10:29:30 EST 2013


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.  ;)



More information about the jbosstools-dev mailing list