mons Developers List , losku...@gmx.de
> Cc: James Carman , Matt Benson
>
> Subject: Re: BCEL 6 API breakage
>
> While I am a big fan of ASM it feels a bit strange to put it forth as a
> great example in this regard.
>
> Indeed some ASM API changes were simple - some weren&#
d this new tech.
Original message
From: Torsten Curdt
Date: 06/07/2016 9:18 PM (GMT-05:00)
To: Commons Developers List , losku...@gmx.de
Cc: James Carman , Matt Benson
Subject: Re: BCEL 6 API breakage
While I am a big fan of ASM it feels a bit strange to put it forth
While I am a big fan of ASM it feels a bit strange to put it forth as a
great example in this regard.
Indeed some ASM API changes were simple - some weren't so much. And many
required source level changes. Some changes are often just a quick refactor
away. If we'd allow just that we'd be a good st
AFAIK ASM already put its users through the pain of BC breakage when they
went from an interface-based design to one based on abstract classes (3 to
4 or 4 to 5) but mixing versions across that boundary is the very
definition of jar hell and is why ASM recommends that their classes be
shaded into a
Hi all,
following on the recent discussion and on the recent mails regarding the
keeping the "old" BCEL namespace for 6.0 I just wanted to share my view on the
BCEL API compatibility story, both from the API contributor/consumer sides,
since I'm playing both roles in projects below.
###
TL;DR
James Carman schrieb am Di., 7. Juni 2016 um
14:36 Uhr:
> On Tue, Jun 7, 2016 at 8:15 AM Jochen Wiedmann
> wrote:
>
> > In the light of the current discussions, you may be right.
> >
> > However, what I still don't understand: Why is BC such an issue for
> people?
> >
> > I think, it is perfectl
On Tue, Jun 7, 2016 at 8:15 AM Jochen Wiedmann
wrote:
> In the light of the current discussions, you may be right.
>
> However, what I still don't understand: Why is BC such an issue for people?
>
> I think, it is perfectly reasonable to do, what other projects do:
>
> - Maintain several release
On Tue, Jun 7, 2016 at 12:57 PM, James Carman
wrote:
> We have to be willing to reevaluate the BC stringency we have had. Is it
> working for our users? Is it worth the trouble it causes (people have left
> this community over it)? Are there better options? Is it too strict and
> could just be rel
uest for it or any discussion about it (I haven't
> read through all the years but around the namespace change last summer).
> The only thing I saw was the Jira request
> https://issues.apache.org/jira/browse/BCEL-222, out of nowhere, and few
> commits later BCEL 6 API was made incompatibl
quest for it or any discussion about it (I haven't read
>> through all the years but around the namespace change last summer). The only
>> thing I saw was the Jira request
>> https://issues.apache.org/jira/browse/BCEL-222, out of nowhere, and few
>> commits later BCEL
w
> commits later BCEL 6 API was made incompatible to every existing client. :-(
> >
> >> I'm a bit suprised that the BCEL API should affect the detectors, but
> >> perhaps there's a good reason for that.
> >
> > BF analyses bytecode, and although we
le to every existing client. :-(
>
>> I'm a bit suprised that the BCEL API should affect the detectors, but
>> perhaps there's a good reason for that.
>
> BF analyses bytecode, and although we have also few recently added ASM based
> detectors (which are mostly BCEL
h are mostly BCEL free), most of the detectors (and
> unfortunately many places in the FB API) use BCEL data structures. It was a
> natural choice 15 years ago, where BCEL was the only one bytecode
> framework...
>
> One way to "fix" the current FindBugs misery is to r
of the detectors (and
unfortunately many places in the FB API) use BCEL data structures. It was a
natural choice 15 years ago, where BCEL was the only one bytecode framework...
One way to "fix" the current FindBugs misery is to replace BCEL with ASM
(asm.tree package &Co) but this req
14 matches
Mail list logo
