On 1 April 2011 02:53, Phil Steitz <phil.ste...@gmail.com> wrote: > On 3/31/11 6:30 PM, sebb wrote: >> Just discovered that Clirr does not complain if the throws clause of a >> method or constructor is changed to add a new Exception. >> Seemed like a bug at first, but it's not, because throws clauses are >> only checked at compile-time. >> >> So e.g. adding "throws IOException" to a method will not break binary >> compatibilty, but of course anyone recompiling against the updated >> binary code will get a compiler error (if they don't already handle >> the error). >> >> [This is perhaps why some incompatibilities in Math 2.x were not >> discovered by Clirr] >> >> The Commons versioning rules require that changes to method signatures >> necessitate a major release, so changes to throws clauses mean a major >> release is required. >> >> Since this does not affect binary compatibility, AFAICT there is no >> technical reason to require a package name change. >> >> A major release generally means that the user will want to make code >> changes anyway to take advantage of new features, so I don't see this >> as a big problem. >> But we should try do document such changes. >> >> Clirr is not sufficient to detect whether a major version change is >> required, so perhaps we need some other tool to detect such changes. >> (Does anyone know of one?) > I don't know if we can afford the license, but the best one I have > seen is "sebb" > he he ;)
Thanks ... > Sorry, could not resist that. I don't know of any better freely > available tools than Clirr. Maybe best to raise an issue there. I could not find anything either, but it turned out not too difficult to use BCEL (*) to scan two classpaths/jars and compare the throws clauses for methods with identical signatures. The tricky bit is where a method has been pulled up to a super-class; I've not entirely solved that yet. But I agree that if Clirr could be extended to also optionally check source compatibility that would be better in the long run, as Clirr already needs to deal with pull-ups etc. I'll raise an enhancement request. (*) started by trying reflection, however that requires all referenced classes to be present on the classpath, including exceptions from 3rd party libs. > Phil >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
