commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [ALL] source compatibility - changes to throws clauses
Date Sun, 03 Apr 2011 23:57:21 GMT
On Sat, Apr 2, 2011 at 6:44 AM, sebb <> wrote:
> On 1 April 2011 02:53, Phil Steitz <> 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:

I used to use it instead of clirr. It covers added exceptions.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message