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. > > -------- 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 > > > > >
