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 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. > 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. > Could you please look over the reports and at the current code base to > determine whether there is anything that needs to get fixed before > cutting a release? > > Thanks > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
