commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: BCEL 6 API breakage
Date Tue, 07 Jun 2016 20:15:26 GMT
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 another namespace.

Java 8 interface default methods would help here, but a library using them,
while preserving API compatibility, would break strict BC simply by
requiring Java 8.
On Jun 7, 2016 2:06 PM, "Andrey Loskutov" <> wrote:

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.

Thanks for keeping the old namespace in the next BCEL release!
Please try to stay compatible in future releases - and your users will stay
with the project.
Break the API often and your users will go away and the project will die.

Eclipse platform project has incredibly long API support and very clear
rules of the API compatibility, see for example
They main rule is: "API Prime Directive: When evolving the Component API
from release to release, do not break existing Clients."

They managed to evolve API's over decade without changing the namespace. It
is really hard (or almost impossible) to break API in Eclipse, and as a
committer you are always under pressure NOT to release any API because
otherwise you must write really good code, because you know, it will stay
almost forever. So it is a big burden for the committer, but is is a
blessing for a plugin provider or system integrator, because you know your
investment will not be wasted with the next release. As a client of the
platform I'm pretty sure that my plugins will most likely work even with
the next major release - and if not, the solution is not far away. I know
for sure that all my time I spent years in different Eclipse projects was
well invested. Sure committers aren't fully free in their decisions, but
they who spent time for this project can be really proud to work on
something which will be used by millions of other people. At same time they
also know how big the responsibility is if they decide to change API.

Another, completely different project is ASM. It does not have that number
of committers, that power and that strict rules as Eclipse, but it also
aims to keep the compatibility as a very important feature.
The purpose of the tool is same as BCEL, and it has a very good
compatibility history, despite the fact that if timely follows on changes
in Java bytecode (see
Although the ASM API compatibility was broken few times, the transition to
the next major release was and is really easy for clients! Since 4.x
release transition to new ASM API's is a no-brainer.

ASM also managed to evolve API's over decade without changing the
namespace. And if you ever used ASM 4.x API, you are pretty sure it would
need just a really small change to use 6.x.
I've switched FindBugs from ASM 5 to ASM 6 in few seconds (the most work
was to replace library name in build files), the actual change was to
replace a single character in the line below:
-    public static final int ASM_VERSION = Opcodes.ASM5;
+    public static final int ASM_VERSION = Opcodes.ASM6;
That is! This one character transition gives ASM clients Java 9 support
"almost for free". Isn't cool? This is the real power of compatibility! I
was done in a second and *everything* still worked!

Why I'm talking about Eclipse and ASM? Both Eclipse and ASM are very
different in they nature, size and governance.
Both projects have exact same resource problems with most committers doing
the job in their free time.
They are also very similar because they have huge success, and one
significant part of this success is because they are very cautious
regarding the API changes, because they care a lot about API clients!
Also one can't really argue Eclipse or ASM aren't innovative because they
care about compatibility. They just trying to deliver both, because they
recognized the value of innovation *and* compatibility. Sure the committers
life could be easier without keeping the API compatibility, but nothing is
for free and success has proved them right.

Let's now take FindBugs. Assume we would release and innovative but fully
incompatible 4.0 version based on the original BCEL6 trunk state before
undoing package renaming.
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. Then suppose there will be Java 9 and
BCEL7. Assume that this will cause another BCEL API breakage, and assume we
will follow with fully incompatible FB 5.0. The small number of 3rd party
providers who managed to stay and migrate to FB 4.0 will see they
investment wasted again. And this time they probably will simply stop
investing into FB plugins forever and switch to ASM/whatever based tools.
Why should they regularly waste they time and money and rewrite they
software just to get it working on a newer JVM? So at the end we will have
no users and a project without users is effectively dead.

Now back to BCEL. Historically this was one of the first and only Java
bytecode frameworks. Honestly speaking, the reason why it is still used
today in 3rd party software (like FindBugs) is because of the investment
costs. We simply cannot afford full switch to ASM because it requires a
huge amount of time (and also because it will break every single client).
If BCEL still have users today, than only those who want stable API's, all
others are already ASM users or users of gazillions other bytecode
manipulation frameworks we have today (mostly ASM based).

API's you have in BCEL *is* the main reason why the project is still used,
and API compatibility (or easy of the transition to the new API) is one of
the biggest features (if not THE feature) you can offer to the existing
BCEL clients. It has  *very* big value!

Sure API can and should evolve, there is no doubt, but it should not be
broken just because "project rule requires it" and "volunteers should have
more fun". If the API must change, then please only because for the real,
important *functional* reasons and in a most gentle way for the API

BTW the *real* fun for volunteer is to implement features by keeping the
compatibility as far as one can manage it. Everyone can write some new fun
code out of nowhere , but the hardest possible challenge for real hacker is
to implement a new feature without breaking existing API clients! This is
the real black art of programming!

On Tuesday 07 June 2016 12:36 James Carman wrote:
> 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
> >
> > I think, it is perfectly reasonable to do, what other projects do:
> >
> > - Maintain several release branches.
> > - Depending on the branch, limit yourself to binary compatible changes,
> > not.
> > - Whenever binary incompatibilities are desirable: Create a new
> > branch, and start to
> >   publish releases out of that branch.
> >
> > So, what is the big deal?
> >
> >
> I totally agree with you, but it is as if this community has a seemingly
> "maintain backward compatibility at all costs" mentality which can be
> tremendously stifling to innovation.  We should be able to maintain (and
> have to for security patches) multiple release streams (2 or 3 seems
> reasonable).  Obviously there's a balance we have to maintain, but I think
> we have been way too far on one side of the spectrum for far too long.
> People just aren't having much fun any more.  For a completely
> volunteer-based work force, fun is important.

Kind regards,

To unsubscribe, e-mail:
For additional commands, e-mail:

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