Re: [jbosstools-dev] Migrating API
----- Original Message -----
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.
How is it any different? I suppose it's OK if you're not using the returned
value, but it's probably still going to cause an exception for anybody actually using
the return value. At that point, what does it matter what type of exception it is? I
think you need to take the "fail early" approach here and use proper types.
> 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. ;)
If you're not thinking ahead, I don't think it matters. Maybe better say, if
you're going to change something, make sure you have a good reason. If you have to
change it, make sure you do it in a compatible way. There are many strategies that can be
used to maintain compatibility (shoot, the refactor functionality in Eclipse actually
allows you to keep the old methods, which delegate to the new).
It is a good thing to highlight that you shouldn't be making interface changes willy
nilly. Then again, I think a lot of times we get around this by not providing a public
API. Heh, look at Dali. ;)