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" <losku...@gmx.de> 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. ### TL;DR 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 https://wiki.eclipse.org/Evolving_Java-based_APIs. 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 http://asm.ow2.org/history.html). 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. But! 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 consumers. 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 <jochen.wiedm...@gmail.com> > 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 branches. > > - Depending on the branch, limit yourself to binary compatible changes, or > > 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 we > 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, google.com/+AndreyLoskutov --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
