commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [ALL] source compatibility - changes to throws clauses
Date Sat, 02 Apr 2011 13:44:45 GMT
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

(*) 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message