On Sat, Apr 2, 2011 at 6:44 AM, sebb <seb...@gmail.com> wrote: > 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.
This might be useful: https://code.google.com/p/osjava/source/browse/#svn%2Ftrunk%2Fjardiff I used to use it instead of clirr. It covers added exceptions. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
