On Thu, Jun 2, 2016 at 1:40 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> 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. > It's a Maven plugin that blows up IIRC. Gary > 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 > -- 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
