Re: [lang] Remove JDK 1.3 workaround from FieldUtils
Hi,
thanks for bringing this up Duncan. I was in a hurry and did not have the time
to write an email, hence the fixme marker.
I've tried to simply delegate to Class.getField(String) in hope that it would
do what we want, but several tests failed. So the first thing to do here would
be to find out if this is really a workaround that can be simplified or if we
still need the code in Java 6. In the latter case the comment should removed to
avoid confusion in the future. I won't have the time to work on this until mid
September, so if anybody else has some spare time, go ahead! :-)
BR,
Benedikt
Send from my mobile device
Am 26.08.2014 um 17:05 schrieb Gary Gregory garydgreg...@gmail.com:
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=1620579r1=1620578r2=1620579view=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
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[lang] Remove JDK 1.3 workaround from FieldUtils
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=1620579r1=1620578r2=1620579view=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.
Kind regards,
Duncan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Remove JDK 1.3 workaround from FieldUtils
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=1620579r1=1620578r2=1620579view=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!
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
Re: [lang] Remove JDK 1.3 workaround from FieldUtils
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=1620579r1=1620578r2=1620579view=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-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
Re: [lang] Remove JDK 1.3 workaround from FieldUtils
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=1620579r1=1620578r2=1620579view=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
