Hi, sebb wrote:
> Hang on please. > > There were plans to produce a new incompatible release with new Maven > coords and new package names. > However as I recall there was some pushback from users who wished to > have a drop-in release. > That is not possible unless the release is binary compatible. The question is, why does one want to have a BC release? If Oliver uses it as drop-in replacement, he will not use any new stuff, i.e. he might be interested to get simply a version working with Java 8 runtime. > So I spent quite a bit of effort reworking the changes so as to > facilitate a binary compatible release. > As far as I can recall, that effort was successful apart from changes > to an interface (or two). > > There were some ideas as to how to resolve the interface > incompatibilty, but no agreement was reached. > I think the options were: > - introduce new interface(s) extending the old one(s) > - keep the interface(s) and handle any runtime errors > - use the Java 8 (?) facility which allows an interface to contain a > method implementation. > > Note that the code does not yet support some Java 8 features. I'd really go on with bcel6 and new GAV using Java 8 as minimum and backport anything to 5.x that is required to let BCEL run on Java 8 runtime, but nothing else. I am normally also in the BC camp, but I realize that we stress it sometimes too much and actually harm further development of a component. After several years of (public) inactivity of a component, we should really take the advantage for a cut. The effort to release an additional 5.x after a major 6.0 is negligible compared to the constant annoyance by the limits of ancient JDKs working on the interesting stuff for a component. Cheers, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
