commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
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 <sebbaz@gmail.com> wrote:
> On 1 April 2011 02:53, Phil Steitz <phil.steitz@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message