On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter <benerit...@gmail.com> wrote:
> dbrosIus <dbros...@baybroadband.net> schrieb am Do., 2. Juni 2016 um > 22:32 Uhr: > > > It is still not functionally compatible. People parsing UNKNOWN > > annotations looking for generics (as was the right way before) will now > > fail. Better rip the generic support out too. > > > > Okay, if this is the case I haven't understood the situation correctly. If > our plan is to make a release that covers Java 8, we should go all the way. > I think the immediate need is to avoid blowing up on Java 8. I see this as a 5.x BC release needed ASAP that the Maven plugin(s) can pick up, also ASAP. Gary > > > > > -------- Original message -------- > > From: Benedikt Ritter <brit...@apache.org> > > Date: 06/02/2016 4:22 PM (GMT-05:00) > > To: Commons Developers List <dev@commons.apache.org> > > Subject: Re: [bcel] Deprecated InstructionConstants > > > > Okay, so were are we now? > > > > - people are waiting for a new release > > - package coords have changed - BC is broken > > - sebb has put effort into making all changes compatible > > - two interface changes remain > > > > Is that correct? Then let's just get over with this two interfaces mach > > make the API redesign afterwards. Let's create two extension interfaces > > release this stuff with the old package and maven coord and we're done. > > > > sebb <seb...@gmail.com> schrieb am Do., 2. Juni 2016 um 14:19 Uhr: > > > > > 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 > > > > > > > > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory