On 2016-12-22, sebb wrote: > On 22 December 2016 at 07:28, Stefan Bodewig <bode...@apache.org> wrote: >> Hi
>> I've managed to build japicmp reports for COMPRESS, the full site of the >> current master is at >> http://stefan.samaflost.de/staging/commons-compress-1.13/ >> If you look at >> http://stefan.samaflost.de/staging/commons-compress-1.13/japicmp-maven-plugin-report.html >> you'll see a few strange things. Some new methods and classes are >> flagged as binary incompatible because they throw checked >> exceptions. This seems to be japicmp, not a real issue with the code. > The report is really hard to read as the only marker is (*) or (!) or blank > Apart from spotting the markers, one has to remember which is which. I completely agree. > I could not find any BC issues. > However there are a few source incompatibilities. > Adding a thrown Exception does affect source compilation of calling > code, but exceptions are not part of method signatures so do not > affect BC. All cases are completely new methods, there is no real incompatibility. This is an artifact of japicmp's comparision. I'll try to see whether the report would look better with a more recent version (parent 42 has switched to a newer one by default). >> But there is one binary incompatible change (a serialization >> incompatibility): UnsupportedZipFeatureException has a new >> serialVersionUID. This is because it really changed its serialization >> from not being serializable at all to being serializable (the old code >> had non-transient non-serializable fields). >> I think this is acceptable. > It's not a BC issue ... > But in any case I think it would be OK. > However, does it really make sense to support serialization? > It can be a lot of work to get right, tends to make it hard to have > immutable classes, and is a source of security holes. The class is an exception and java.lang.Exception is Serializable. It's not a choice we've made ourselves. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
