commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [BCEL] Breaking changes in 6.1 needed by Tomcat (?)
Date Fri, 01 Sep 2017 05:41:24 GMT
Hi again,

> Am 31.08.2017 um 01:38 schrieb sebb <sebbaz@gmail.com>:
> 
> On 30 August 2017 at 20:11, Benedikt Ritter <britter@apache.org <mailto:britter@apache.org>>
wrote:
>> Hi,
>> 
>> looking through the JavaDoc comments in the Visitor interface, it looks like we added
additional methods in the 6.0 release. 6.0 was a major release but without package and maven
coords change. Seems like we accepted this kind of changes for 6.0. I’m not sure what point
I’m trying to make here… But the whole versioning/api evolution thingy looks pretty messy
in BCEL.
> 
> A major version bump does not require changes to package names/maven coords.
> It just means that there have been major changes.
> 
> However changing package/maven coords is a major change and so
> requires a major version bump.
> 
> AFAIK 6.0 was binary compatible with the previous release.
> That was certainly the intention.

Looking through the 6.0 release notes [1] I’m thinking about going the same way again. It
seems to be necessary to extend the Visitor interface to implement new features. Introducing
a new VisitorN extends VisitorN-1 very release seems like overkill. So maybe the best solution
to get more opinions on this is to roll an RC and see what people think.

Regards,
Benedikt

[1] https://www.apache.org/dist/commons/bcel/RELEASE-NOTES.txt <https://www.apache.org/dist/commons/bcel/RELEASE-NOTES.txt>
> 
>> Cheers,
>> Benedikt
>> 
>>> Am 30.08.2017 um 16:37 schrieb Gary Gregory <garydgregory@gmail.com>:
>>> 
>>> We recently dealt with this kind of compatibility issue in Log4j 2 and we
>>> decided to subclass the interface in question. I suggest we do the same
>>> here. Not pretty but it is type safe and bullet-proof.
>>> 
>>> Gary
>>> 
>>> On Tue, Aug 29, 2017 at 5:17 AM, sebb <sebbaz@gmail.com> wrote:
>>> 
>>>> On 28 August 2017 at 20:07, Gary Gregory <garydgregory@gmail.com> wrote:
>>>>> The question is whether this breaks binary compatibility. If it does,
>>>> this
>>>>> needs fixing. Unless there are other important changes that warrant a
>>>> major
>>>>> version, I would go the sub-interface route; ugly, but workable within
>>>> the
>>>>> same major release.
>>>> 
>>>> According to [1], it seems it does not.
>>>> 
>>>> However it will break source compatibility if a 3rd party implements
>>>> the interface.
>>>> 
>>>> Also I seem to remember there were some concerns about the downstream
>>>> effect for 3rd party visitor implementations.
>>>> 
>>>> IIRC it was that BCEL will expect to be able to invoke the new
>>>> methods; this will fail.
>>>> There may be ways around this by catching the exception.
>>>> 
>>>> The dev list should have the details.
>>>> 
>>>> [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html
>>>> 
>>>>> Gary
>>>>> 
>>>>> On Mon, Aug 28, 2017 at 12:58 PM, Benedikt Ritter <britter@apache.org>
>>>>> wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Rev. 1782852 [1] has introduced two breaking changes by adding the
>>>> methods:
>>>>>> 
>>>>>> public void visitAnnotation(org.apache.bcel.classfile.Annotations)
>>>>>> public void visitAnnotationDefault(org.apache.bcel.classfile.
>>>>>> AnnotationDefault)
>>>>>> 
>>>>>> to the interface org.apache.bcel.classfile.Visitor. The commit comment
>>>>>> indicates that these changes are needed by the Tomcat project. How
do we
>>>>>> want to deal with this for the upcoming 6.1 release? I see several
>>>> options:
>>>>>> 
>>>>>> - accept these changes and make it explicit in release notes
>>>>>> - add a new interface which extends from the Visitor interface and
add
>>>> the
>>>>>> new methods to that interface
>>>>>> - major version bump (probably not the best idea…)
>>>>>> 
>>>>>> Thoughts?
>>>>>> Benedikt
>>>>>> 
>>>>>> [1] http://svn.apache.org/viewvc?view=revision&revision=1782852
<
>>>>>> http://svn.apache.org/viewvc?view=revision&revision=1782852>
>>>> 
>>>> ---------------------------------------------------------------------
>>>> 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 <mailto:dev-unsubscribe@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:dev-unsubscribe@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message