There is a huge difference between 4 and 5. But Java 6 does not offer much, so I say stick with Java 5 unless the code needs Java 6.
On 25 April 2014 23:09, Gary Gregory <garydgreg...@gmail.com> wrote: > We should update the JRE requirement to a least java 6. > > G > > <div>-------- Original message --------</div><div>From: sebb > <seb...@gmail.com> </div><div>Date:04/25/2014 17:50 (GMT-05:00) > </div><div>To: Commons Developers List <dev@commons.apache.org> > </div><div>Subject: Re: [bcel] Next release </div><div> > </div>Also, JDK 1.4 is really old now; it's highly unlikely that anyone is > stuck on it. > > But if there are other significant changes I don't object to a major > version bump. > > On 25 April 2014 15:49, Gary Gregory <garydgreg...@gmail.com> wrote: >> FWIW: We've changed Java requirements in minor releases before. >> >> Gary >> >> >> On Fri, Apr 25, 2014 at 10:47 AM, Dave Brosius <dbros...@apache.org> wrote: >> >>> I think it should be 6.0 since we've changed from requiring jdk1.4 to >>> jdk1.5 and that really shouldn't be done on a point release. >>> >>> --- >>> <br type="_moz" /> >>> >>> >>> On 2014-04-25 08:57, Gary Gregory wrote: >>> >>>> Either version # is fine with me. >>>> >>>> Gary >>>> >>>> >>>> On Fri, Apr 25, 2014 at 8:40 AM, Torsten Curdt <tcu...@vafer.org> wrote: >>>> >>>> Go go go! Thanks for looking into this :) >>>>> >>>>> IIRC there is so much stuff fixed and changed from 5.2 - I think >>>>> calling it 6.0 expresses this better than 5.3. >>>>> Especially with the changes to the visitor interface. >>>>> >>>>> cheers, >>>>> Torsten >>>>> >>>>> On Fri, Apr 25, 2014 at 12:30 PM, Emmanuel Bourg <ebo...@apache.org> >>>>> wrote: >>>>> > Hi all, >>>>> > >>>>> > I'm currently working on the migration to Java 8 in Debian and several >>>>> > packages are broken due to the lack of invokedynamic support in BCEL >>>>> 5.2 >>>>> > (the dreaded ClassFormatException: Invalid byte tag in constant pool: >>>>> > 18). I think it's high time for a release. Even if the current code >>>>> > isn't perfect it's far better than BCEL 5.2 (there are ~60 issues fixed >>>>> > in JIRA). >>>>> > >>>>> > The code on the trunk isn't fully compatible with the previous release >>>>> > due to the addition of methods to the Visitor interface. By Commons >>>>> > standards we would usually change the package, however I think it's >>>>> safe >>>>> > to keep the org.apache.bcel package as is. The Visitor interface is >>>>> > never implemented directly, I have found that projects always extend >>>>> the >>>>> > EmptyVisitor class instead. I've rebuilt several projects using BCEL >>>>> > (ant, ant-contrib, clirr, clirr-maven-plugin, ha-jdbc, jbossas, jibx, >>>>> > mx4j, xalan, maven-shared-jar, robocode) and they all worked fine with >>>>> > the current snapshot. >>>>> > >>>>> > The code on the trunk is numbered 6.0, are we ok with that or should we >>>>> > use 5.3 for the next release? >>>>> > >>>>> > Emmanuel Bourg >>>>> > >>>>> > --------------------------------------------------------------------- >>>>> > 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 >>>>> >>>>> >>>>> >>> --------------------------------------------------------------------- >>> 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 > > --------------------------------------------------------------------- > 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