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:46 GMT
On Thu, Jun 2, 2016 at 1:40 PM, Gary Gregory <garydgregory@gmail.com> wrote:

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

It's a Maven plugin that blows up IIRC.

Gary


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



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