commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [lang] Remove JDK 1.3 workaround from FieldUtils
Date Tue, 26 Aug 2014 14:17:58 GMT
On 26 August 2014 13:40, Gary Gregory <garydgregory@gmail.com> wrote:
> On Tue, Aug 26, 2014 at 8:38 AM, Duncan Jones <djones@apache.org> wrote:
>
>> Hi Benedikt,
>>
>> On 26 August 2014 12:53,  <britter@apache.org> wrote:
>> > Author: britter
>> > Date: Tue Aug 26 11:53:51 2014
>> > New Revision: 1620579
>> >
>> > URL: http://svn.apache.org/r1620579
>> > Log:
>> > Add fixme regarding a JDK 1.3 workaround
>> >
>> > Modified:
>> >
>>  commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java
>> >
>> > Modified:
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java
>> > URL:
>> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java?rev=1620579&r1=1620578&r2=1620579&view=diff
>> >
>> ==============================================================================
>> > ---
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java
>> (original)
>> > +++
>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java
>> Tue Aug 26 11:53:51 2014
>> > @@ -85,6 +85,7 @@ public class FieldUtils {
>> >      public static Field getField(final Class<?> cls, final String
>> fieldName, final boolean forceAccess) {
>> >          Validate.isTrue(cls != null, "The class must not be null");
>> >          Validate.isTrue(StringUtils.isNotBlank(fieldName), "The field
>> name must not be blank/empty");
>> > +        // FIXME is this workaround still needed? lang requires Java 6
>> >          // Sun Java 1.3 has a bugged implementation of getField hence
>> we write the
>> >          // code ourselves
>>
>> Perhaps this is something to discuss on the ML. If we have sufficient
>> test coverage in that area, we could just remove the code and check it
>> still builds successfully using 1.6. Unless anyone shouts out with a
>> good reason why the code should stay.
>>
>
> It seems reasonable to remove code that depends on Java 1.3 behavior!

That is not the issue; the code does _not_ depend on the behaviour of Java 1.3.

The issue is that a work-round was added for problematic behaviour
detected in Java 1.3
Once the work-round is in place the code will work equally well
whether or not the JVM bug is fixed.

Are we 100% sure that no later JVM implementations have the same issue?

> Gary
>
>
>>
>> Kind regards,
>>
>> Duncan
>>
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message