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