Re: BCEL 6 API breakage

9:18 PM (GMT-05:00) > To: Commons Developers List <dev@commons.apache.org>, losku...@gmx.de > Cc: James Carman <ja...@carmanconsulting.com>, Matt Benson > <gudnabr...@gmail.com> > Subject: Re: BCEL 6 API breakage > > While I am a big fan of ASM it feels a bit st

Re: BCEL 6 API breakage

tech.  Original message From: Torsten Curdt <tcu...@vafer.org> Date: 06/07/2016 9:18 PM (GMT-05:00) To: Commons Developers List <dev@commons.apache.org>, losku...@gmx.de Cc: James Carman <ja...@carmanconsulting.com>, Matt Benson <gudnabr...@gmail.com>

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'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

Re: BCEL 6 API breakage

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

Re: BCEL 6 API breakage

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

Re: BCEL 6 API breakage

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

Re: BCEL 6 API breakage

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: > >

Re: BCEL 6 API breakage

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

Re: BCEL 6 API breakage

ng list and I was surprised > that I saw no real request 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

Re: BCEL 6 API breakage

>> that I saw no real request 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 nowher

Re: BCEL 6 API breakage

owse/BCEL-222, out of nowhere, and few > 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 an

Re: BCEL 6 API breakage

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 have also few recently added ASM based > detectors (which

Re: BCEL 6 API breakage

y 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 replace BCEL wit

BCEL 6 API breakage

d 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 ) but this requires lot of ef