On Tue, Aug 26, 2014 at 10:17 AM, sebb <seb...@gmail.com> wrote: > On 26 August 2014 13:40, Gary Gregory <garydgreg...@gmail.com> wrote: > > On Tue, Aug 26, 2014 at 8:38 AM, Duncan Jones <djo...@apache.org> wrote: > > > >> Hi Benedikt, > >> > >> On 26 August 2014 12:53, <brit...@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? >
I do not know if all 1.6 JVM (on all platforms) have such an issue. Seems like a tall order to test. Gary > > Gary > > > > > >> > >> Kind regards, > >> > >> Duncan > >> > >> > > >> > > >> > > >> > >> --------------------------------------------------------------------- > >> 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 > > -- 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
