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

Reply via email to