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:27:34 GMT
On Thu, Jun 2, 2016 at 1:22 PM, Benedikt Ritter <britter@apache.org> wrote:

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

Check. Do you want to RM? Or Sebb?

Gary


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