commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dbrosIus <>
Subject Re: BCEL 6 API breakage
Date Wed, 08 Jun 2016 01:32:45 GMT
I have almost certainly the largest FindBugs plug in.  I expect it will take less than 15
minutes to update it to use a breaking package/api version of BCEL if it ever was to go out. 
I've got this fancy thing called a text editor with search/replace. I pity those who haven't
adopted this new tech. 

-------- Original message --------
From: Torsten Curdt <> 
Date: 06/07/2016  9:18 PM  (GMT-05:00) 
To: Commons Developers List <>, 
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'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 step further.

BCEL has committed some horrible (and I mean horrible!) API sins (one word:
"static"). There is just no way those can be solved without breaking
anything (if there ever is going to be enough progress forward).

Of course there are investment costs - but that doesn't mean you can/should
expect upgrades at cost zero. It's not like we have enough dev resources to
actually turn BCEL around like that for that major changes anyway (I

ALL existing FB plugins will immediately stop working, because we expose
> BCEL API to clients. We will get a shit storm on the mailing list and few
> plugin providers will simply give up.

I guess that should raise a couple of questions for the FB dev team:
- Do you really need to expose BCEL through the plugin API? Was that a wise
- Why will people not just update the plugins? Why will there be a
- Why not help the plugin providers?
- Will those changes be really so hard to apply?

It's not about "volunteers should have more fun" but finding people to do
the job.
Living in the past just does not help with that.

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