[jira] [Commented] (LANG-417) ClassUtils: method for turning FQN into resource path
[
https://issues.apache.org/jira/browse/LANG-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874934#comment-13874934
]
Paul Benedict commented on LANG-417:
Good names. I approve.
> ClassUtils: method for turning FQN into resource path
> -
>
> Key: LANG-417
> URL: https://issues.apache.org/jira/browse/LANG-417
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Paul Benedict
>Assignee: Benedikt Ritter
> Fix For: 3.3, Patch Needed
>
>
> I commonly need a FQ path to a resource within the same location as a class
> file. I recommend the addition of this method:
> {code:java}
> public String getPackageResourcePath(Class clazz, String resourceName)
> StringBuffer buf = new StringBuffer();
> buf.append(ClassUtils.getPackageName(getClass()).replace('.', '/'));
> buf.append("/");
> buf.append(resourceName);
> return buf.toString();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (SCXML-186) Groovy expression evaluator
[ https://issues.apache.org/jira/browse/SCXML-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874876#comment-13874876 ] Ate Douma commented on SCXML-186: - I've just committed a bunch and AFAIK completed this feature, at least for initial support. I'll keep the issue open for a while longer though as I intend to add more javadoc (although there already is some), and as such a big new feature it also demands its own user guide documentation as well. This I will continue to work on and provide updates over the coming weeks, while actually also start leveraging this feature for our own project. But right now it already is quite usable, and to get a mini impression of how, please take a look at: http://svn.apache.org/viewvc/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml2/env/groovy/serializable-initial-base-script.xml?revision=1559147&view=markup > Groovy expression evaluator > --- > > Key: SCXML-186 > URL: https://issues.apache.org/jira/browse/SCXML-186 > Project: Commons SCXML > Issue Type: New Feature >Reporter: Woonsan Ko >Assignee: Ate Douma > Fix For: 2.0 > > > A Groovy expression evaluator for SCXML expression can offer richer > functionality which cannot be supported by the other simpler expression > evaluator. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (LANG-637) There should be a DifferenceBuilder with a ReflectionDifferenceBuilder implementation
[
https://issues.apache.org/jira/browse/LANG-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874867#comment-13874867
]
Duncan Jones commented on LANG-637:
---
I think {{Iterable}} is a good choice.
> There should be a DifferenceBuilder with a ReflectionDifferenceBuilder
> implementation
> -
>
> Key: LANG-637
> URL: https://issues.apache.org/jira/browse/LANG-637
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.builder.*
>Reporter: Eric Lewis
>Priority: Minor
> Fix For: 3.3, Review Patch
>
> Attachments: Diff.java, DiffBuilder.java, DiffBuilderTest.java,
> DiffList.java, DiffListTest.java, DiffTest.java, Diffable.java,
> commons-lang3-LANG-637-complete.patch, commons-lang3-LANG-637.patch
>
>
> The ToStringBuilder and ReflectionToStringBuilder are great tools for
> everyday development.
> We use them to show all the properties in an object, which comes handy
> especially for testing.
> However, JUnit with its assertEquals() just outputs the toString() of the two
> compared objects. For complex objects, this becomes unreadable.
> So, it would be great to have a DifferenceBuilder with a
> ReflectionDifferenceBuilder implementation to be able to get only the
> differing properties of two objects. The question is whether the two objects
> would have to be of the same type or not.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (LANG-417) ClassUtils: method for turning FQN into resource path
[
https://issues.apache.org/jira/browse/LANG-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874865#comment-13874865
]
Benedikt Ritter commented on LANG-417:
--
This sounds good to me. What do [~paul4christ79] and [~bayard] think?
> ClassUtils: method for turning FQN into resource path
> -
>
> Key: LANG-417
> URL: https://issues.apache.org/jira/browse/LANG-417
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Paul Benedict
>Assignee: Benedikt Ritter
> Fix For: 3.3, Patch Needed
>
>
> I commonly need a FQ path to a resource within the same location as a class
> file. I recommend the addition of this method:
> {code:java}
> public String getPackageResourcePath(Class clazz, String resourceName)
> StringBuffer buf = new StringBuffer();
> buf.append(ClassUtils.getPackageName(getClass()).replace('.', '/'));
> buf.append("/");
> buf.append(resourceName);
> return buf.toString();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (LANG-939) Move Documentation from user guide to package-info files
[
https://issues.apache.org/jira/browse/LANG-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter resolved LANG-939.
--
Resolution: Fixed
{{Committed revision 1559146.}}
> Move Documentation from user guide to package-info files
>
>
> Key: LANG-939
> URL: https://issues.apache.org/jira/browse/LANG-939
> Project: Commons Lang
> Issue Type: Task
> Components: General
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
> Fix For: 3.3
>
>
> As discussed on the ML [1], the user guide on the website currently contains
> documentation that would better suite in the corresponding package-info
> files. The Documentation should be split up and moved to those files.
> [1] http://markmail.org/message/jgyacp3pv3t43s4h
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (LANG-939) Move Documentation from user guide to package-info files
[ https://issues.apache.org/jira/browse/LANG-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-939: - Affects Version/s: (was: 3.2) > Move Documentation from user guide to package-info files > > > Key: LANG-939 > URL: https://issues.apache.org/jira/browse/LANG-939 > Project: Commons Lang > Issue Type: Task > Components: General >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > Fix For: 3.3 > > > As discussed on the ML [1], the user guide on the website currently contains > documentation that would better suite in the corresponding package-info > files. The Documentation should be split up and moved to those files. > [1] http://markmail.org/message/jgyacp3pv3t43s4h -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (LANG-939) Move Documentation from user guide to package-info files
[ https://issues.apache.org/jira/browse/LANG-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-939: - Fix Version/s: (was: Patch Needed) > Move Documentation from user guide to package-info files > > > Key: LANG-939 > URL: https://issues.apache.org/jira/browse/LANG-939 > Project: Commons Lang > Issue Type: Task > Components: General >Affects Versions: 3.2 >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > Fix For: 3.3 > > > As discussed on the ML [1], the user guide on the website currently contains > documentation that would better suite in the corresponding package-info > files. The Documentation should be split up and moved to those files. > [1] http://markmail.org/message/jgyacp3pv3t43s4h -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (LANG-939) Move Documentation from user guide to package-info files
[ https://issues.apache.org/jira/browse/LANG-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874795#comment-13874795 ] Benedikt Ritter commented on LANG-939: -- I'm working on this now. > Move Documentation from user guide to package-info files > > > Key: LANG-939 > URL: https://issues.apache.org/jira/browse/LANG-939 > Project: Commons Lang > Issue Type: Task > Components: General >Affects Versions: 3.2 >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > Fix For: 3.3 > > > As discussed on the ML [1], the user guide on the website currently contains > documentation that would better suite in the corresponding package-info > files. The Documentation should be split up and moved to those files. > [1] http://markmail.org/message/jgyacp3pv3t43s4h -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (SCXML-187) Add support for initial SCXML script (SCXML spec 3.2.2: children)
[ https://issues.apache.org/jira/browse/SCXML-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ate Douma resolved SCXML-187. - Resolution: Fixed Feature committed > Add support for initial SCXML script (SCXML spec 3.2.2: children) > -- > > Key: SCXML-187 > URL: https://issues.apache.org/jira/browse/SCXML-187 > Project: Commons SCXML > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Ate Douma >Assignee: Ate Douma > Fix For: 2.0 > > > The SCXML spec [1] section 3.2.2 children, defines as an allowable > child element: > -
[jira] [Updated] (SCXML-187) Add support for initial SCXML script (SCXML spec 3.2.2: children)
[ https://issues.apache.org/jira/browse/SCXML-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ate Douma updated SCXML-187: Description: The SCXML spec [1] section 3.2.2 children, defines as an allowable child element: -
[jira] [Created] (SCXML-187) Add support for initial SCXML script (SCXML spec 3.2.2: children)
Ate Douma created SCXML-187: --- Summary: Add support for initial SCXML script (SCXML spec 3.2.2: children) Key: SCXML-187 URL: https://issues.apache.org/jira/browse/SCXML-187 Project: Commons SCXML Issue Type: New Feature Affects Versions: 2.0 Reporter: Ate Douma Assignee: Ate Douma Fix For: 2.0 The SCXML spec [1] section 3.2.2 children, defines as an allowable child element: -
[jira] [Commented] (LANG-939) Move Documentation from user guide to package-info files
[ https://issues.apache.org/jira/browse/LANG-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874719#comment-13874719 ] Benedikt Ritter commented on LANG-939: -- Making changes is an issue, yes. But if we really try to push out release more frequently, this is not too bad. I don't understand what you mean with only new users get the improvements. We publish the API doc on the website. That's where users currently find the user guide. It will be still available there, so even if you use an older version of [lang], you can still look ab the current package JavaDoc. > Move Documentation from user guide to package-info files > > > Key: LANG-939 > URL: https://issues.apache.org/jira/browse/LANG-939 > Project: Commons Lang > Issue Type: Task > Components: General >Affects Versions: 3.2 >Reporter: Benedikt Ritter > Fix For: 3.3, Patch Needed > > > As discussed on the ML [1], the user guide on the website currently contains > documentation that would better suite in the corresponding package-info > files. The Documentation should be split up and moved to those files. > [1] http://markmail.org/message/jgyacp3pv3t43s4h -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (LANG-613) ConstructorUtils.getAccessibleConstructor() Does Not Check the Accessibility of Enclosing Classes
[ https://issues.apache.org/jira/browse/LANG-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874717#comment-13874717 ] Benedikt Ritter commented on LANG-613: -- [~bentels]: I can not apply your patch, without the ICLA, since I would have to modify your code. I'm only allowed to do this if you have the ICLA filled or if you resubmit a modified patch (ICLA would be better...). TIA! > ConstructorUtils.getAccessibleConstructor() Does Not Check the Accessibility > of Enclosing Classes > - > > Key: LANG-613 > URL: https://issues.apache.org/jira/browse/LANG-613 > Project: Commons Lang > Issue Type: Bug > Components: lang.reflect.* >Affects Versions: 3.0 >Reporter: David M. Sledge >Assignee: Benedikt Ritter >Priority: Minor > Labels: patch > Fix For: 3.3, Review Patch > > Attachments: > LANG-613_Recursive_visibility_check_up_the_enclosing_tree.patch > > > ConstructorUtils.getAccessibleConstructor() checks if the declaring class is > public but not whether it's a top-level class or an enclosed one. > Consequently, with enclosed declaring classes, the method does not check if > the enclosing class is public, or it's enclosing class, or it's enclosing > class, etc... -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (LANG-943) Test DurationFormatUtilsTest.testEdgeDuration fails in JDK 1.6, 1.7 and 1.8, BRST time zone
[ https://issues.apache.org/jira/browse/LANG-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874716#comment-13874716 ] Benedikt Ritter commented on LANG-943: -- [~kinow] where do you set the TimeZone? In setUp()? Feel free to resolve this issue in trunk. I will make sure the fix doesn't break anything in my TimeZone and hopefully the others will check some additional time zones, when I roll out 3.3 > Test DurationFormatUtilsTest.testEdgeDuration fails in JDK 1.6, 1.7 and 1.8, > BRST time zone > --- > > Key: LANG-943 > URL: https://issues.apache.org/jira/browse/LANG-943 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 3.1, 3.2, 3.2.1 > Environment: Apache Maven 3.1.1 > (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 12:22:22-0300) > Maven home: /opt/java/apache-maven-3.1.1 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "3.11.0-14-generic", arch: "amd64", family: "unix" > JDK 1.6.0_27, JDK 1.7.0_25, JDK 1.7.0_25 >Reporter: Bruno P. Kinoshita > Labels: test-fail, timezone > Fix For: 3.3, Patch Needed > > > While helping testing LANG-942 with JDK1.8 I always got three tests failing, > while others had 2. After @britter fixed the issues related to JDK1.8, I > continue getting errors with JDK1.8. > I decided to vote for [lang] 3.2.1 and test the tag with JDK 1.8 and a few > others. However, I'm getting errors with any JDK, 1.6, 1.7 and 1.8 (build > 121). Always the same error: > Failed tests: > > DurationFormatUtilsTest.testEdgeDurations:467->assertEqualDuration:562->assertEqualDuration:575 > expected:<7[7]> but was:<7[6]> > I get the same error with JDK 1.6 and the tag 3.1 > Since the test is somewhat related to Time Zones (there are some Calendar's, > TimeZone.getDefault(), etc), here's my locale and time zone: > kinow@chuva:~/java/apache/commons-lang-31$ locale > LANG=en_US.UTF-8 > LANGUAGE=en_US > LC_CTYPE="en_US.UTF-8" > LC_NUMERIC="en_US.UTF-8" > LC_TIME="en_US.UTF-8" > LC_COLLATE="en_US.UTF-8" > LC_MONETARY="en_US.UTF-8" > LC_MESSAGES="en_US.UTF-8" > LC_PAPER="en_US.UTF-8" > LC_NAME="en_US.UTF-8" > LC_ADDRESS="en_US.UTF-8" > LC_TELEPHONE="en_US.UTF-8" > LC_MEASUREMENT="en_US.UTF-8" > LC_IDENTIFICATION="en_US.UTF-8" > LC_ALL= > kinow@chuva:~/java/apache/commons-lang-31$ date > Sun Jan 5 21:23:05 BRST 2014 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (LANG-951) Fragments are wrong by 1 day when using fragment YEAR or MONTH
[
https://issues.apache.org/jira/browse/LANG-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874715#comment-13874715
]
Benedikt Ritter commented on LANG-951:
--
Hello Sebastian,
would it be possible that you create a patch file that contains a junit test
that fails without the proposed fix and is successful after including it?
Also, if you plan to contribute on a regular basis (which I would appreciate
;-) ) you should file an [Individual Contributor Licence
Agreement|http://www.apache.org/licenses/].
Thanks!
Benedikt
> Fragments are wrong by 1 day when using fragment YEAR or MONTH
> --
>
> Key: LANG-951
> URL: https://issues.apache.org/jira/browse/LANG-951
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
>Reporter: Sebastian Götz
> Fix For: 3.3, Review Patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When one trys to get the fragments of a calendar object and uses the fragment
> YEAR or MONTH, the returned value is wrong by 1 day in the targeted timeunit.
> The bug resides in the class *DateUtils* in function
> {code}
> private static long getFragment(Calendar calendar, int fragment, int unit)
> {code}
> There is an initial recalculation if the fragment is YEAR or MONTH. So if one
> would like to have the minutes for the fragment YEAR for the date 2000-01-01
> 00:00:00 this would return 1440 which is actually wrong. The error can be
> found on lines 1635 - 1643.
> Suggested fix:
> {code}
> // Fragments bigger than a day require a breakdown to days
> switch (fragment) {
> case Calendar.YEAR:
> result += ((calendar.get(Calendar.DAY_OF_YEAR)-1) *
> MILLIS_PER_DAY) / millisPerUnit;
> break;
> case Calendar.MONTH:
> result += ((calendar.get(Calendar.DAY_OF_MONTH)-1) *
> MILLIS_PER_DAY) / millisPerUnit;
> break;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (LANG-417) ClassUtils: method for turning FQN into resource path
[
https://issues.apache.org/jira/browse/LANG-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874712#comment-13874712
]
Woonsan Ko commented on LANG-417:
-
Good point.
{{ClasspathUtils}} seems better to me because many frameworks have used
'classpath:' url scheme already and so 'ClasspathUtils' seems connected to that
to me.
Also, I wasn't fully happy with 'toAbsoluteName' either even though it was
copied from the javadoc.
So, how about this then? The names are longer, but it looks clearer than
'AbsoluteResource[Name|Path]' to me. :-)
{code}
public class ClasspathUtils {
public static String toFullyQualifiedResourceName(Package context, name);
public static String toFullyQualifiedResourceName(Class context, name);
}
{code}
> ClassUtils: method for turning FQN into resource path
> -
>
> Key: LANG-417
> URL: https://issues.apache.org/jira/browse/LANG-417
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Paul Benedict
>Assignee: Benedikt Ritter
> Fix For: 3.3, Patch Needed
>
>
> I commonly need a FQ path to a resource within the same location as a class
> file. I recommend the addition of this method:
> {code:java}
> public String getPackageResourcePath(Class clazz, String resourceName)
> StringBuffer buf = new StringBuffer();
> buf.append(ClassUtils.getPackageName(getClass()).replace('.', '/'));
> buf.append("/");
> buf.append(resourceName);
> return buf.toString();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (MATH-1089) Precision.round() returns different results when provided negative zero as double or float
[ https://issues.apache.org/jira/browse/MATH-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874659#comment-13874659 ] Gilles commented on MATH-1089: -- Committed in revision 1559067. > Precision.round() returns different results when provided negative zero as > double or float > -- > > Key: MATH-1089 > URL: https://issues.apache.org/jira/browse/MATH-1089 > Project: Commons Math > Issue Type: Bug >Reporter: Thomas Neidhart > Fix For: 3.3 > > Attachments: MATH-1089.patch > > > Precision.round(-0.0d, x) = 0.0 > Precision.round(-0.0f, x) = -0.0 > After discussion on the mailinglist, the result should always be -0.0. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (MATH-1089) Precision.round() returns different results when provided negative zero as double or float
[ https://issues.apache.org/jira/browse/MATH-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874649#comment-13874649 ] Thomas Neidhart commented on MATH-1089: --- Yes, this solution is cleaner, feel free to already commit the patch. > Precision.round() returns different results when provided negative zero as > double or float > -- > > Key: MATH-1089 > URL: https://issues.apache.org/jira/browse/MATH-1089 > Project: Commons Math > Issue Type: Bug >Reporter: Thomas Neidhart > Fix For: 3.3 > > Attachments: MATH-1089.patch > > > Precision.round(-0.0d, x) = 0.0 > Precision.round(-0.0f, x) = -0.0 > After discussion on the mailinglist, the result should always be -0.0. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (LANG-417) ClassUtils: method for turning FQN into resource path
[
https://issues.apache.org/jira/browse/LANG-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874644#comment-13874644
]
Benedikt Ritter edited comment on LANG-417 at 1/17/14 10:38 AM:
I'm not sure whether {{toAbsoluteName}} is a good method name. I always
associate "absolute" with the file system root. Maybe {{ClasspathUtils}} is a
better name than ResourceUtils? Then it would make sense to determine the
absolute name in the class path.
was (Author: britter):
I'm not sure whether {{toAbsoluteName}} is a good method name. I always
associate "absolute" with the file system root.
> ClassUtils: method for turning FQN into resource path
> -
>
> Key: LANG-417
> URL: https://issues.apache.org/jira/browse/LANG-417
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Paul Benedict
>Assignee: Benedikt Ritter
> Fix For: 3.3, Patch Needed
>
>
> I commonly need a FQ path to a resource within the same location as a class
> file. I recommend the addition of this method:
> {code:java}
> public String getPackageResourcePath(Class clazz, String resourceName)
> StringBuffer buf = new StringBuffer();
> buf.append(ClassUtils.getPackageName(getClass()).replace('.', '/'));
> buf.append("/");
> buf.append(resourceName);
> return buf.toString();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (LANG-417) ClassUtils: method for turning FQN into resource path
[
https://issues.apache.org/jira/browse/LANG-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874644#comment-13874644
]
Benedikt Ritter commented on LANG-417:
--
I'm not sure whether {{toAbsoluteName}} is a good method name. I always
associate "absolute" with the file system root.
> ClassUtils: method for turning FQN into resource path
> -
>
> Key: LANG-417
> URL: https://issues.apache.org/jira/browse/LANG-417
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Paul Benedict
>Assignee: Benedikt Ritter
> Fix For: 3.3, Patch Needed
>
>
> I commonly need a FQ path to a resource within the same location as a class
> file. I recommend the addition of this method:
> {code:java}
> public String getPackageResourcePath(Class clazz, String resourceName)
> StringBuffer buf = new StringBuffer();
> buf.append(ClassUtils.getPackageName(getClass()).replace('.', '/'));
> buf.append("/");
> buf.append(resourceName);
> return buf.toString();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (MATH-1089) Precision.round() returns different results when provided negative zero as double or float
[ https://issues.apache.org/jira/browse/MATH-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-1089: - Attachment: MATH-1089.patch I propose the attached patch; overall it is probably faster, though the absolute speed difference will be marginal in most cases. > Precision.round() returns different results when provided negative zero as > double or float > -- > > Key: MATH-1089 > URL: https://issues.apache.org/jira/browse/MATH-1089 > Project: Commons Math > Issue Type: Bug >Reporter: Thomas Neidhart > Fix For: 3.3 > > Attachments: MATH-1089.patch > > > Precision.round(-0.0d, x) = 0.0 > Precision.round(-0.0f, x) = -0.0 > After discussion on the mailinglist, the result should always be -0.0. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (LANG-637) There should be a DifferenceBuilder with a ReflectionDifferenceBuilder implementation
[
https://issues.apache.org/jira/browse/LANG-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13872513#comment-13872513
]
Benedikt Ritter edited comment on LANG-637 at 1/17/14 8:40 AM:
---
I've set this to 3.3 so that we finally can include this. I plan to roll out
3.3 in early feburary.
I'm not sure wether DiffList should implement the List interface. Random access
doesn't seem to be a requirement here as well as the possibility to mutate the
result. Maybe we're better off with {{DiffResult implements Iterable}}.
WDYT?
was (Author: britter):
I've set this to 3.3 so that we finally can include this. I plan to roll out
3.3 in early feburary.
I'm not sure wether DiffList should implement the List interface. Random access
doesn't seem to be a requirement here as well as the possibility to mutate the
result. Maybe we're better off with {{DiffResult implements Iterable}.
WDYT?
> There should be a DifferenceBuilder with a ReflectionDifferenceBuilder
> implementation
> -
>
> Key: LANG-637
> URL: https://issues.apache.org/jira/browse/LANG-637
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.builder.*
>Reporter: Eric Lewis
>Priority: Minor
> Fix For: 3.3, Review Patch
>
> Attachments: Diff.java, DiffBuilder.java, DiffBuilderTest.java,
> DiffList.java, DiffListTest.java, DiffTest.java, Diffable.java,
> commons-lang3-LANG-637-complete.patch, commons-lang3-LANG-637.patch
>
>
> The ToStringBuilder and ReflectionToStringBuilder are great tools for
> everyday development.
> We use them to show all the properties in an object, which comes handy
> especially for testing.
> However, JUnit with its assertEquals() just outputs the toString() of the two
> compared objects. For complex objects, this becomes unreadable.
> So, it would be great to have a DifferenceBuilder with a
> ReflectionDifferenceBuilder implementation to be able to get only the
> differing properties of two objects. The question is whether the two objects
> would have to be of the same type or not.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
