You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stefan Bodewig <bo...@apache.org> on 2016/12/22 07:28:11 UTC
[compress] nearing 1.13 release, backwards incompatible change(?)
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.
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.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] nearing 1.13 release, backwards incompatible change(?)
Posted by Stefan Bodewig <bo...@apache.org>.
On 2016-12-22, Gary Gregory wrote:
> It would be nice if you could push a Commons Parent release as well.
Never done that, but I can try.
> My RC1 failed on that front.
Why did it fail?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] nearing 1.13 release, backwards incompatible change(?)
Posted by Gary Gregory <ga...@gmail.com>.
It would be nice if you could push a Commons Parent release as well. My RC1
failed on that front.
Gary
On Thu, Dec 22, 2016 at 2:38 AM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2016-12-22, Stefan Bodewig wrote:
>
> > On 2016-12-22, Stefan Bodewig wrote:
>
> >> On 2016-12-22, sebb wrote:
>
> >>> 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).
>
> > The report generated with 0.9.1 unfortunately still claims completely
> > new methods that throw checked exceptions would break binary
> > compatibility.
>
> Ah, fixed in 0.9.3, I've updated
> http://stefan.samaflost.de/staging/commons-compress-1.13/
> japicmp-maven-plugin-report.html
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [compress] nearing 1.13 release, backwards incompatible change(?)
Posted by Stefan Bodewig <bo...@apache.org>.
On 2016-12-22, Stefan Bodewig wrote:
> On 2016-12-22, Stefan Bodewig wrote:
>> On 2016-12-22, sebb wrote:
>>> 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).
> The report generated with 0.9.1 unfortunately still claims completely
> new methods that throw checked exceptions would break binary
> compatibility.
Ah, fixed in 0.9.3, I've updated
http://stefan.samaflost.de/staging/commons-compress-1.13/japicmp-maven-plugin-report.html
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] nearing 1.13 release, backwards incompatible change(?)
Posted by Stefan Bodewig <bo...@apache.org>.
On 2016-12-22, Stefan Bodewig wrote:
> On 2016-12-22, sebb wrote:
>> 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).
The report generated with 0.9.1 unfortunately still claims completely
new methods that throw checked exceptions would break binary
compatibility.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] nearing 1.13 release, backwards incompatible change(?)
Posted by Stefan Bodewig <bo...@apache.org>.
On 2016-12-22, sebb wrote:
> On 22 December 2016 at 07:28, Stefan Bodewig <bo...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] nearing 1.13 release, backwards incompatible change(?)
Posted by sebb <se...@gmail.com>.
On 22 December 2016 at 07:28, Stefan Bodewig <bo...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org