commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [bcel] Deprecated InstructionConstants
Date Thu, 02 Jun 2016 20:40:13 GMT
On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter <beneritter@gmail.com>
wrote:

> dbrosIus <dbrosIus@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 <britter@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 <sebbaz@gmail.com> schrieb am Do., 2. Juni 2016 um 14:19 Uhr:
> >
> > > On 2 June 2016 at 12:35, Jörg Schaible <joerg.schaible@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-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message