On 2 June 2016 at 12:35, Jörg Schaible <joerg.schai...@bpm-inspire.com> wrote: > 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
Not sure I agree the effort is negligible. > compared to the constant annoyance by the limits of ancient JDKs working on > the interesting stuff for a component. The JDK required to run BCEL is orthogonal to compatibility. Indeed there was a proposal to use Java 8 default interface methods to get round the issue with compatibility. Please let's not conflate the two issues. > Cheers, > Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
