[jira] [Updated] (LANG-915) Wrong locale handling in LocaleUtils.toLocale()
[ https://issues.apache.org/jira/browse/LANG-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-915: --- Fix Version/s: (was: Patch Needed) Review Patch > Wrong locale handling in LocaleUtils.toLocale() > --- > > Key: LANG-915 > URL: https://issues.apache.org/jira/browse/LANG-915 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 3.1 >Reporter: Sergio Fernández >Priority: Minor > Fix For: Review Patch > > Attachments: LANG-915.patch, LANG-915-test.patch > > > The static method LocaleUtils.toLocale() fails, at least, to parse 3-char > locale strings, which are completelly valid BCP47 locales. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-848) Improve StringUtils.is(Not)Blank with a CharSequence... version
[
https://issues.apache.org/jira/browse/LANG-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797614#comment-13797614
]
Henri Yandell commented on LANG-848:
My main thought is that the JVM should auto-convert an Iterable to an Object[]
for varargs :)
Failing that, I think we should have an ArrayUtils.iteratorToArray() method.
public static E[] iteratorToArray(Iterator iterator);
That would allow for StringUtils.isAnyBlank(
ArrayUtils.iteratorToArray(somecharacterList.iterator()) );
I'm not sure if I'm playing too fast and loose with the generics there without
trying it :) I think we need the varargs versions of methods, but I'm not
convinced by the need for Iterable. It increases the code and typically our
code isn't stream based - ie: people in restricted memory situations can create
custom versions of the function they want.
> Improve StringUtils.is(Not)Blank with a CharSequence... version
> ---
>
> Key: LANG-848
> URL: https://issues.apache.org/jira/browse/LANG-848
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.1
>Reporter: Alexander Muthmann
> Fix For: 3.2
>
>
> Currently it's only possible to compare a single CharSequence per
> is(Not)Blank/is(Not)Empty call.
> This should be changed to support multiple CharSequences in a single call.
> {code}
> if(StringUtils.isNotBlank(foo) && StringUtils.isNotBlank(bar) && ...)
> {code}
> could be changed to
> {code}
> if(StringUtils.isNotBlank(foo, bar, ...)
> {code}
> As there are two possible ways to combine the results (AND and OR), it'd be
> necessary to create multiple methods.
> {code}
> isAnyBlank(CharSequence... cs)
> isNoneBlank(CharSequence... cs)
> isAnyEmpty(CharSequence... cs)
> isNoneEmpty(CharSequence... cs)
> {code}
> I could implement those methods and contribute them via github if there is
> any interest from project's side.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-922) Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...)
[ https://issues.apache.org/jira/browse/LANG-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797610#comment-13797610 ] Henri Yandell commented on LANG-922: +1 on both counts. isOneTrue okay if isAnyTrue is there. > Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of > BooleanUtils.xor(booleans...) > > > Key: LANG-922 > URL: https://issues.apache.org/jira/browse/LANG-922 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > Fix For: 3.2 > > > The old implementation (prior to r1532476) of BooleanUtils.xor(boolean...) > checked if the provided array contained exactly one boolean with value true. > This was changed because it is not the correct behavior for an XOR operation. > To preserve the behavior we should add BooleanUtils.isOneTrue(boolean...) and > BooleanUtils.isOneTrue(Boolean...) (and possibly the equivalents for > isOneFalse). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1043) MathUtils.sum() method to add together a bunch of numbers.
[ https://issues.apache.org/jira/browse/MATH-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797479#comment-13797479 ] Henri Yandell commented on MATH-1043: - Moved over. Patch needed for ArithmeticUtils. > MathUtils.sum() method to add together a bunch of numbers. > -- > > Key: MATH-1043 > URL: https://issues.apache.org/jira/browse/MATH-1043 > Project: Commons Math > Issue Type: New Feature > Environment: Any >Reporter: Matt Bishop >Priority: Minor > > I find myself doing sums frequently with a variety of numbers. It would be > nice if MathUtils had a method like this: > int add(int... numbers); -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Moved] (MATH-1043) MathUtils.sum() method to add together a bunch of numbers.
[ https://issues.apache.org/jira/browse/MATH-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell moved LANG-912 to MATH-1043: -- Component/s: (was: lang.math.*) Fix Version/s: (was: 3.x) Affects Version/s: (was: 3.1) Workflow: classic default workflow (was: Default workflow, editable Closed status) Key: MATH-1043 (was: LANG-912) Project: Commons Math (was: Commons Lang) > MathUtils.sum() method to add together a bunch of numbers. > -- > > Key: MATH-1043 > URL: https://issues.apache.org/jira/browse/MATH-1043 > Project: Commons Math > Issue Type: New Feature > Environment: Any >Reporter: Matt Bishop >Priority: Minor > > I find myself doing sums frequently with a variety of numbers. It would be > nice if MathUtils had a method like this: > int add(int... numbers); -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (IO-400) IOUtils: add support for copying from large byte buffers
[
https://issues.apache.org/jira/browse/IO-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb closed IO-400.
---
> IOUtils: add support for copying from large byte buffers
>
>
> Key: IO-400
> URL: https://issues.apache.org/jira/browse/IO-400
> Project: Commons IO
> Issue Type: New Feature
>Reporter: Sebb
> Fix For: 2.5
>
>
> Trying to write a large byte array to a FileOutputStream may cause OOME.
> This is because such output requires the use of native code, and native code
> may need to copy the array in order to access it safely, see:
> http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html#wp1265
> It might therefore be useful to have a method which writes from the byte
> array in chunks. One can create a ByteArrayInputStream from the input, and
> then use one of the copy() methods, but that creates an unnecessary array
> buffer (albeit only 4k).
> There are already write methods which copy byte[] to OutputStream and char[]
> to Writer.
> Some or all of these could be converted to use chunked output, or there could
> be new methods to implement the chunking.
> Here is a sample implementation of a stand-alone method:
> {code}
> public static void writeChunked(byte[] data, OutputStream output) throws
> IOException {
> int bytes = data.length;
> int offset = 0;
> while(bytes > 0) {
> int chunk = Math.min(bytes, DEFAULT_BUFFER_SIZE);
> output.write(data, offset, chunk);
> bytes -= chunk;
> offset += chunk;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (IO-400) IOUtils: add support for copying from large byte buffers
[
https://issues.apache.org/jira/browse/IO-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved IO-400.
-
Resolution: Duplicate
Fix Version/s: 2.5
> IOUtils: add support for copying from large byte buffers
>
>
> Key: IO-400
> URL: https://issues.apache.org/jira/browse/IO-400
> Project: Commons IO
> Issue Type: New Feature
>Reporter: Sebb
> Fix For: 2.5
>
>
> Trying to write a large byte array to a FileOutputStream may cause OOME.
> This is because such output requires the use of native code, and native code
> may need to copy the array in order to access it safely, see:
> http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html#wp1265
> It might therefore be useful to have a method which writes from the byte
> array in chunks. One can create a ByteArrayInputStream from the input, and
> then use one of the copy() methods, but that creates an unnecessary array
> buffer (albeit only 4k).
> There are already write methods which copy byte[] to OutputStream and char[]
> to Writer.
> Some or all of these could be converted to use chunked output, or there could
> be new methods to implement the chunking.
> Here is a sample implementation of a stand-alone method:
> {code}
> public static void writeChunked(byte[] data, OutputStream output) throws
> IOException {
> int bytes = data.length;
> int offset = 0;
> while(bytes > 0) {
> int chunk = Math.min(bytes, DEFAULT_BUFFER_SIZE);
> output.write(data, offset, chunk);
> bytes -= chunk;
> offset += chunk;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-848) Improve StringUtils.is(Not)Blank with a CharSequence... version
[
https://issues.apache.org/jira/browse/LANG-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797017#comment-13797017
]
Benedikt Ritter commented on LANG-848:
--
Well the question appears why we don't have Validate.isOneNull(), isAnyNull etc
and we're currently talking about the same in LANG-922. All for varagrs and
Iterables. Not sure if it's a good idea to go down that road.
Thoughts?
> Improve StringUtils.is(Not)Blank with a CharSequence... version
> ---
>
> Key: LANG-848
> URL: https://issues.apache.org/jira/browse/LANG-848
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.1
>Reporter: Alexander Muthmann
> Fix For: 3.2
>
>
> Currently it's only possible to compare a single CharSequence per
> is(Not)Blank/is(Not)Empty call.
> This should be changed to support multiple CharSequences in a single call.
> {code}
> if(StringUtils.isNotBlank(foo) && StringUtils.isNotBlank(bar) && ...)
> {code}
> could be changed to
> {code}
> if(StringUtils.isNotBlank(foo, bar, ...)
> {code}
> As there are two possible ways to combine the results (AND and OR), it'd be
> necessary to create multiple methods.
> {code}
> isAnyBlank(CharSequence... cs)
> isNoneBlank(CharSequence... cs)
> isAnyEmpty(CharSequence... cs)
> isNoneEmpty(CharSequence... cs)
> {code}
> I could implement those methods and contribute them via github if there is
> any interest from project's side.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-790) Null safe Navigation in ObjectUtils
[ https://issues.apache.org/jira/browse/LANG-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796978#comment-13796978 ] Benedikt Ritter commented on LANG-790: -- This is already possible with BeanUtils. See [PropertyUtils.getNestedProperty(Object, String)|http://commons.apache.org/proper/commons-beanutils/javadocs/v1.8.3/apidocs/index.html] > Null safe Navigation in ObjectUtils > --- > > Key: LANG-790 > URL: https://issues.apache.org/jira/browse/LANG-790 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Reporter: Gokul Nanthakumar C > > Adding a method for null safe navigation of objects will be very helpful. for > example a method like > ObjectUtils.getValue(Object obj, String "path", String defaultValue); > ex :ObjectUtils.getValue(myObject, "x.y.z", "default"); > it will navigate in the myObject like myObject.getX().getY().getZ(), if any > thing in the path is null (x,y or z), it will return the default value. > It will be really useful, it is like null safe navigation in groovy. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-922) Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...)
[ https://issues.apache.org/jira/browse/LANG-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796973#comment-13796973 ] Benedikt Ritter commented on LANG-922: -- I think for booleans there are special cases like isOneTrue, isAnyTrue, isOneFalse, isAnyFalse. We could implement the suggested method in ArrayUtils but that would require us to do this for all primitives and for the gerenic type T. IMHO we should definitely implement the old behavior. Don't know when I'll find the time to do this :-) Maybe I can have a look on friday. Regarding the name: isOneTrue is clear if you also have isAnyTrue, WDYT? > Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of > BooleanUtils.xor(booleans...) > > > Key: LANG-922 > URL: https://issues.apache.org/jira/browse/LANG-922 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > Fix For: 3.2 > > > The old implementation (prior to r1532476) of BooleanUtils.xor(boolean...) > checked if the provided array contained exactly one boolean with value true. > This was changed because it is not the correct behavior for an XOR operation. > To preserve the behavior we should add BooleanUtils.isOneTrue(boolean...) and > BooleanUtils.isOneTrue(Boolean...) (and possibly the equivalents for > isOneFalse). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-915) Wrong locale handling in LocaleUtils.toLocale()
[ https://issues.apache.org/jira/browse/LANG-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergio Fernández updated LANG-915: -- Attachment: LANG-915.patch Please, find attached a patch for solving the issue with the method LocaleUtils.toLocale() and ISO 639-3 codes, including: * Completely re-implementation of the locale parsing, due the complexity for adapt the new feature in the current code. * Implementation compliant with the current tests at LocaleUtilsTest. An invalid assert has been removed. * Added new test for testing 3-chars locale * Added a new methof StringUtils.occurrences() which I commonly need, and I needed for this path, although at the end I needed the splited array, so not used in the submitted version. So it could be removed if you don't find it relevant. > Wrong locale handling in LocaleUtils.toLocale() > --- > > Key: LANG-915 > URL: https://issues.apache.org/jira/browse/LANG-915 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 3.1 >Reporter: Sergio Fernández >Priority: Minor > Fix For: Patch Needed > > Attachments: LANG-915.patch, LANG-915-test.patch > > > The static method LocaleUtils.toLocale() fails, at least, to parse 3-char > locale strings, which are completelly valid BCP47 locales. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-915) Wrong locale handling in LocaleUtils.toLocale()
[ https://issues.apache.org/jira/browse/LANG-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergio Fernández updated LANG-915: -- Attachment: LANG-915-test.patch Sure. Please, find attached a patch for the test suite that arises the issue. Later I'd try to provide a patch for the issue itself, since a quick look is not enough because the current code implements a very cryptic algorithm with too many magic numbers in it > Wrong locale handling in LocaleUtils.toLocale() > --- > > Key: LANG-915 > URL: https://issues.apache.org/jira/browse/LANG-915 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 3.1 >Reporter: Sergio Fernández >Priority: Minor > Fix For: Patch Needed > > Attachments: LANG-915-test.patch > > > The static method LocaleUtils.toLocale() fails, at least, to parse 3-char > locale strings, which are completelly valid BCP47 locales. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (SCXML-172) Improve CustomActionTest not to depend on test method execution order
[ https://issues.apache.org/jira/browse/SCXML-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko resolved SCXML-172. -- Resolution: Fixed > Improve CustomActionTest not to depend on test method execution order > - > > Key: SCXML-172 > URL: https://issues.apache.org/jira/browse/SCXML-172 > Project: Commons SCXML > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Woonsan Ko >Assignee: Woonsan Ko >Priority: Minor > Fix For: 2.0 > > > The CustomActionTest#testCustomActionCallbacks() depends on method execution > order (@FixMethodOrder(MethodSorters.JVM)). > However, the MethodSorters.JVM option may give inconsistent results in > different JVMs. [1] > I think we'd better do the following: > - Remove #testCustomActionCallbacks(); > - In each test method executing SCXML with Hello custom action, we can > compare the expected execution times on Hello custom action with the recorded > execution number in Hello class. (Each number can be reinitialized in > @Before.) > This would give more flexibility even when testing only each test method > (e.g, 'mvn test -Dtest=CustomActionTest#testSomething). > [1] http://junit.czweb.org/apidocs/org/junit/runners/MethodSorters.html#JVM -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SCXML-172) Improve CustomActionTest not to depend on test method execution order
[ https://issues.apache.org/jira/browse/SCXML-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796828#comment-13796828 ] Woonsan Ko commented on SCXML-172: -- Fixed by removing #testCustomActionCallbacks() and moving the code checking Hello custom action execution times into each relevant test method. > Improve CustomActionTest not to depend on test method execution order > - > > Key: SCXML-172 > URL: https://issues.apache.org/jira/browse/SCXML-172 > Project: Commons SCXML > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Woonsan Ko >Assignee: Woonsan Ko >Priority: Minor > Fix For: 2.0 > > > The CustomActionTest#testCustomActionCallbacks() depends on method execution > order (@FixMethodOrder(MethodSorters.JVM)). > However, the MethodSorters.JVM option may give inconsistent results in > different JVMs. [1] > I think we'd better do the following: > - Remove #testCustomActionCallbacks(); > - In each test method executing SCXML with Hello custom action, we can > compare the expected execution times on Hello custom action with the recorded > execution number in Hello class. (Each number can be reinitialized in > @Before.) > This would give more flexibility even when testing only each test method > (e.g, 'mvn test -Dtest=CustomActionTest#testSomething). > [1] http://junit.czweb.org/apidocs/org/junit/runners/MethodSorters.html#JVM -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (SCXML-172) Improve CustomActionTest not to depend on test method execution order
Woonsan Ko created SCXML-172: Summary: Improve CustomActionTest not to depend on test method execution order Key: SCXML-172 URL: https://issues.apache.org/jira/browse/SCXML-172 Project: Commons SCXML Issue Type: Improvement Affects Versions: 2.0 Reporter: Woonsan Ko Assignee: Woonsan Ko Priority: Minor Fix For: 2.0 The CustomActionTest#testCustomActionCallbacks() depends on method execution order (@FixMethodOrder(MethodSorters.JVM)). However, the MethodSorters.JVM option may give inconsistent results in different JVMs. [1] I think we'd better do the following: - Remove #testCustomActionCallbacks(); - In each test method executing SCXML with Hello custom action, we can compare the expected execution times on Hello custom action with the recorded execution number in Hello class. (Each number can be reinitialized in @Before.) This would give more flexibility even when testing only each test method (e.g, 'mvn test -Dtest=CustomActionTest#testSomething). [1] http://junit.czweb.org/apidocs/org/junit/runners/MethodSorters.html#JVM -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (SCXML-171) Upgrade JUnit dependency to 4.11
[ https://issues.apache.org/jira/browse/SCXML-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko resolved SCXML-171. -- Resolution: Fixed Dave Brosius fixed this. Thanks again! > Upgrade JUnit dependency to 4.11 > > > Key: SCXML-171 > URL: https://issues.apache.org/jira/browse/SCXML-171 > Project: Commons SCXML > Issue Type: Task >Affects Versions: 2.0 >Reporter: Woonsan Ko >Assignee: Woonsan Ko > Fix For: 2.0 > > > Better update to JUnit 4.11; Would be nicer for new comers. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SCXML-171) Upgrade JUnit dependency to 4.11
[ https://issues.apache.org/jira/browse/SCXML-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796770#comment-13796770 ] Woonsan Ko commented on SCXML-171: -- Thanks a lot, [~dbrosius], for the changing all those test classes! I think I still want to improve CustomActionTest not to depend on method execution order, but verify execution times in each test method (this will make it more useful even when testing only test method as well) instead of having a test method to check the accumulated execution times before. But this improvement can be achieved with another JIRA issue. I'll create a new issue for that. Cheers, Woonsan > Upgrade JUnit dependency to 4.11 > > > Key: SCXML-171 > URL: https://issues.apache.org/jira/browse/SCXML-171 > Project: Commons SCXML > Issue Type: Task >Affects Versions: 2.0 >Reporter: Woonsan Ko >Assignee: Woonsan Ko > Fix For: 2.0 > > > Better update to JUnit 4.11; Would be nicer for new comers. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SCXML-171) Upgrade JUnit dependency to 4.11
[ https://issues.apache.org/jira/browse/SCXML-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796755#comment-13796755 ] Ate Douma commented on SCXML-171: - [~woon_san] be aware Dave Brosius already did the full upgrade last night, thereby more or less making this issue obsolete... > Upgrade JUnit dependency to 4.11 > > > Key: SCXML-171 > URL: https://issues.apache.org/jira/browse/SCXML-171 > Project: Commons SCXML > Issue Type: Task >Affects Versions: 2.0 >Reporter: Woonsan Ko >Assignee: Woonsan Ko > Fix For: 2.0 > > > Better update to JUnit 4.11; Would be nicer for new comers. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SCXML-171) Upgrade JUnit dependency to 4.11
[
https://issues.apache.org/jira/browse/SCXML-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796695#comment-13796695
]
Woonsan Ko commented on SCXML-171:
--
Hi Rahul,
Thanks for the suggestion. I tried it with the option, but it fails, too.
It succeeds with the following option instead:
{code}
@FixMethodOrder(MethodSorters.JVM)
public class CustomActionTest {
{code}
However, as pointed out in its javadoc [1], the MethodSorters.JVM option may
give inconsistent results in different JVMs.
So, I think I should increase the expected execution count on Hello action in
the test class and verify if the expected execution count is the same as the
count internally stored in the Hello static member. I think that's what
CustomActionTest#testCustomActionCallbacks() wanted to achieve.
I'll commit it today. Please take a review. Thanks in advance!
Cheers,
Woonsan
[1] http://junit.czweb.org/apidocs/org/junit/runners/MethodSorters.html#JVM
> Upgrade JUnit dependency to 4.11
>
>
> Key: SCXML-171
> URL: https://issues.apache.org/jira/browse/SCXML-171
> Project: Commons SCXML
> Issue Type: Task
>Affects Versions: 2.0
>Reporter: Woonsan Ko
>Assignee: Woonsan Ko
> Fix For: 2.0
>
>
> Better update to JUnit 4.11; Would be nicer for new comers.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: (was: MATH-1041_Comparator.patch) > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_MathArrays.patch, > MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: MATH-1041_MathArrays.patch MATH-1041_Comparator.patch > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_MathArrays.patch, > MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796667#comment-13796667 ] Sean Owen commented on MATH-1041: - I will prepare one more patch with the naming changes and javadoc. From there you should feel free to edit further before you commit. Separately, on of() vs create(), I would also note that the Pair in Apache Crunch, and 4 Pair classes in the JDK, have an "of()" method. It does seem more natural to me as well. But I'm not going to make that change in this patch. There is an internal usage of a Pair Comparator already. It seems not such a big thing to simply expose that. I will attach an additional patch showing how it can replace the existing other Comparator, but this is of course entirely optional. > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CSV-101) String split with an escape pattern
[
https://issues.apache.org/jira/browse/CSV-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796641#comment-13796641
]
Emmanuel Bourg commented on CSV-101:
I'm not sure that fits better in commons-csv. I have never seen a csv file with
an escape pattern instead of a simple delimiter for example.
> String split with an escape pattern
> ---
>
> Key: CSV-101
> URL: https://issues.apache.org/jira/browse/CSV-101
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Reporter: Michael Knapp
>Priority: Minor
> Labels: patch, split
> Attachments: StringUtilsSplitEscapingly.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Often times there are strings which are delimited, but certain patterns can
> escape the delimiter. For example, quotes are used in CSV to escape a comma
> delimiter. I have written a couple methods for StringUtils that split
> strings while considering the possibility of an escape pattern. For example,
> when given "a,\"b,c\",c", it will produce {"a","\"b,c\"","c"}. In my code,
> the delimiter can be a string, and it can be escaped by any regular
> expression pattern. Unit tests are already written and passing.
> I plan to attach the patch for this once the ticket is created. I just need
> a committer to review the patch, approve, and commit it for me.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796628#comment-13796628 ] Gilles commented on MATH-1041: -- Also, if CM implemented its own "Pair" for _internal_ purposes. It might not make a lot of sense to provide extended functionality (such as the comparator) until we really have a need for it. Users that need such functionality would indeed be better off using the Lang's implementation! > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796620#comment-13796620 ] Gilles commented on MATH-1041: -- bq. [...] it gets strange if different method names are used to do the same. In principle, I agree of course, but the question is whether we should have consistency with Lang in preference to internal consistency. If I'm not mistaken, we have (or are going to have) other factory methods, and it won't make sense to name those "of". If the CM's Pair is _really_ intended as a placeholder for the Lang's class, and it is foreseeable that the "no dependency" requirement will be dropped, then I would be fine changing the name. If it's here to stay, I'd slightly favour internal consistency... :) > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796613#comment-13796613 ] Gilles commented on MATH-1041: -- bq. But here I meant that within one issue you had me invite discussion to iterate on the patch but had twice committed part of it before those changes completed. I indicated (see my first comment) that I could handle the modifications by myself; hence I started as soon as Phil indicated he was OK with the suggestions. So let's work together in an orderly fashion. ;) # IMO, the changes for "Pair.java" are completed: I think that the additional tests are not necessary as they duplicate what the constructor's tests ought to do. # Comparator ## For clarity, the comparator name should be changed to "PairLexicographicComparator". ## All fields and methods must be commented: ### "compare" method. What you wrote in the class comment could be moved there; and in the class comment, you could put a '@link' to the "compare" method. ### field "nullsFirst" (to be renamed also, see below). ## "nullsFirst" could better be renamed either "nullIsFirst" or "nullFirst". > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796609#comment-13796609 ] Joerg Schaible commented on MATH-1041: -- @Gilles: Please reconsider the name of the factory method. Pair of Commons Lang has Pair.of(K,V). IIRC Pair of Math started as copy to avoid the dependency, but it gets strange if different method names are used to do the same. > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796597#comment-13796597 ] Sean Owen commented on MATH-1041: - OK. This had felt like so minor as to be one issue to me, but I can see breaking it into two. But here I meant that within one issue you had me invite discussion to iterate on the patch but had twice committed part of it before those changes completed. Truly no big deal, but I figured it would just save you trouble to converge on the right patch and then commit. (I still have some extra tests outstanding on the 'patch' side FWIW.) You are welcome to commit any variation on the proposed changed here that you see fit. Thanks Gilles, don't let me burn any more of your cycles. > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-731) Better Javadoc for BitField class
[ https://issues.apache.org/jira/browse/LANG-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-731: --- Fix Version/s: (was: 3.x) Patch Needed > Better Javadoc for BitField class > - > > Key: LANG-731 > URL: https://issues.apache.org/jira/browse/LANG-731 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 3.0 >Reporter: Gary Gregory > Fix For: Patch Needed > > > As mentioned in [LANG-730], the class is hard to understand. The current > Javadocs are minimal. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-848) Improve StringUtils.is(Not)Blank with a CharSequence... version
[
https://issues.apache.org/jira/browse/LANG-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-848:
---
Fix Version/s: (was: 3.x)
3.2
> Improve StringUtils.is(Not)Blank with a CharSequence... version
> ---
>
> Key: LANG-848
> URL: https://issues.apache.org/jira/browse/LANG-848
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.1
>Reporter: Alexander Muthmann
> Fix For: 3.2
>
>
> Currently it's only possible to compare a single CharSequence per
> is(Not)Blank/is(Not)Empty call.
> This should be changed to support multiple CharSequences in a single call.
> {code}
> if(StringUtils.isNotBlank(foo) && StringUtils.isNotBlank(bar) && ...)
> {code}
> could be changed to
> {code}
> if(StringUtils.isNotBlank(foo, bar, ...)
> {code}
> As there are two possible ways to combine the results (AND and OR), it'd be
> necessary to create multiple methods.
> {code}
> isAnyBlank(CharSequence... cs)
> isNoneBlank(CharSequence... cs)
> isAnyEmpty(CharSequence... cs)
> isNoneEmpty(CharSequence... cs)
> {code}
> I could implement those methods and contribute them via github if there is
> any interest from project's side.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-848) Improve StringUtils.is(Not)Blank with a CharSequence... version
[
https://issues.apache.org/jira/browse/LANG-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796594#comment-13796594
]
Henri Yandell commented on LANG-848:
Response was low, with a note that we should support Iterable. I'm not sure it
warrants supporting Iterable though as other StringUtils methods don't do that
when they support varargs.
+1 for including in 3.2.
> Improve StringUtils.is(Not)Blank with a CharSequence... version
> ---
>
> Key: LANG-848
> URL: https://issues.apache.org/jira/browse/LANG-848
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.1
>Reporter: Alexander Muthmann
> Fix For: 3.2
>
>
> Currently it's only possible to compare a single CharSequence per
> is(Not)Blank/is(Not)Empty call.
> This should be changed to support multiple CharSequences in a single call.
> {code}
> if(StringUtils.isNotBlank(foo) && StringUtils.isNotBlank(bar) && ...)
> {code}
> could be changed to
> {code}
> if(StringUtils.isNotBlank(foo, bar, ...)
> {code}
> As there are two possible ways to combine the results (AND and OR), it'd be
> necessary to create multiple methods.
> {code}
> isAnyBlank(CharSequence... cs)
> isNoneBlank(CharSequence... cs)
> isAnyEmpty(CharSequence... cs)
> isNoneEmpty(CharSequence... cs)
> {code}
> I could implement those methods and contribute them via github if there is
> any interest from project's side.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (LANG-912) MathUtils.sum() method to add together a bunch of numbers.
[ https://issues.apache.org/jira/browse/LANG-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796588#comment-13796588 ] Henri Yandell edited comment on LANG-912 at 10/16/13 9:12 AM: -- I can't seem to see anything in Math for this however. Perhaps this is too simple :) I've mailed the dev list. was (Author: bayard): I can't seem to see anything in Math for this however. Perhaps this is too simple :) > MathUtils.sum() method to add together a bunch of numbers. > -- > > Key: LANG-912 > URL: https://issues.apache.org/jira/browse/LANG-912 > Project: Commons Lang > Issue Type: New Feature > Components: lang.math.* >Affects Versions: 3.1 > Environment: Any >Reporter: Matt Bishop >Priority: Minor > Fix For: 3.x > > > I find myself doing sums frequently with a variety of numbers. It would be > nice if MathUtils had a method like this: > int add(int... numbers); -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-883) StringUtils.containsAny(CharSequence, CharSequence... )
[ https://issues.apache.org/jira/browse/LANG-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-883: --- Fix Version/s: (was: 3.x) Patch Needed > StringUtils.containsAny(CharSequence, CharSequence... ) > --- > > Key: LANG-883 > URL: https://issues.apache.org/jira/browse/LANG-883 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Affects Versions: 3.1 >Reporter: Ivan Hristov >Priority: Trivial > Fix For: Patch Needed > > > Presently there is a: public static boolean containsAny(CharSequence cs, > char... searchChars). It would be useful to have the: public static boolean > containsAny(CharSequence cs, CharSequence... searchCharSequences) which will > return true if any of the searchCharSequences are contained within the cs. If > you decide to implement it, it would be nice to have an alias method for > collections, e.g., public static boolean containsAny(CharSequence cs, > Collection searchCharSequences) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-912) MathUtils.sum() method to add together a bunch of numbers.
[ https://issues.apache.org/jira/browse/LANG-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796588#comment-13796588 ] Henri Yandell commented on LANG-912: I can't seem to see anything in Math for this however. Perhaps this is too simple :) > MathUtils.sum() method to add together a bunch of numbers. > -- > > Key: LANG-912 > URL: https://issues.apache.org/jira/browse/LANG-912 > Project: Commons Lang > Issue Type: New Feature > Components: lang.math.* >Affects Versions: 3.1 > Environment: Any >Reporter: Matt Bishop >Priority: Minor > Fix For: 3.x > > > I find myself doing sums frequently with a variety of numbers. It would be > nice if MathUtils had a method like this: > int add(int... numbers); -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796587#comment-13796587 ] Gilles commented on MATH-1041: -- bq. Let's do all-or-nothing for the remainder to keep this simple. As I said, commits _must_ be done separately for independent issues. > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (LANG-840) Codebase fails checkstyle checks.
[ https://issues.apache.org/jira/browse/LANG-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-840. -- Resolution: Fixed Closing this issue with the parts of the patch that currently flag in the checkstyle report (from Maven) applied. I'm not sure on the Eclipse vs Maven side of things, but as that issue exists for many projects I'm hesitant to add IDE specific settings. > Codebase fails checkstyle checks. > - > > Key: LANG-840 > URL: https://issues.apache.org/jira/browse/LANG-840 > Project: Commons Lang > Issue Type: Improvement > Components: General >Affects Versions: 3.2 >Reporter: Duncan Jones >Priority: Minor > Fix For: 3.2 > > Attachments: commons-lang3-checkstyle-LANG-840.patch > > > The project currently has a large number of Checkstyle errors. The majority > of these are in the test classes, which either need a major cleanup exercise > or should be excluded from the checks. > The errors on the non-test code are not too numerous and the attached patch > corrects all but one of these. The patch also adds a suppression file that > removes the test classes from the Checkstyle checks. With the patch applied, > I'm able to withstand having Checkstyle auto-running in my IDE. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-840) Codebase fails checkstyle checks.
[ https://issues.apache.org/jira/browse/LANG-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-840: --- Fix Version/s: (was: 3.3) 3.2 > Codebase fails checkstyle checks. > - > > Key: LANG-840 > URL: https://issues.apache.org/jira/browse/LANG-840 > Project: Commons Lang > Issue Type: Improvement > Components: General >Affects Versions: 3.2 >Reporter: Duncan Jones >Priority: Minor > Fix For: 3.2 > > Attachments: commons-lang3-checkstyle-LANG-840.patch > > > The project currently has a large number of Checkstyle errors. The majority > of these are in the test classes, which either need a major cleanup exercise > or should be excluded from the checks. > The errors on the non-test code are not too numerous and the attached patch > corrects all but one of these. The patch also adds a suppression file that > removes the test classes from the Checkstyle checks. With the patch applied, > I'm able to withstand having Checkstyle auto-running in my IDE. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: (was: MATH-1041_Pair.patch) > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796581#comment-13796581 ] Sean Owen commented on MATH-1041: - Ah I see you have committed part of the patch again. One more update coming. Let's do all-or-nothing for the remainder to keep this simple. > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: MATH-1041_Pair.patch MATH-1041_Comparator.patch > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-603) Removes "implement Cloneable" from StrBuilder
[ https://issues.apache.org/jira/browse/LANG-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-603: --- Fix Version/s: (was: 2.x) > Removes "implement Cloneable" from StrBuilder > - > > Key: LANG-603 > URL: https://issues.apache.org/jira/browse/LANG-603 > Project: Commons Lang > Issue Type: Bug > Components: lang.text.* >Affects Versions: 2.2 >Reporter: Jason Ng Yong Liang >Priority: Trivial > > I know this will be fixed in 3.0; meanwhile however, it's confusing people > when they try to use the clone method, only to find that it's not visible. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-677) DateUtils.isSameLocalTime does not work correct
[ https://issues.apache.org/jira/browse/LANG-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-677: --- Fix Version/s: (was: 2.x) 2.7 > DateUtils.isSameLocalTime does not work correct > --- > > Key: LANG-677 > URL: https://issues.apache.org/jira/browse/LANG-677 > Project: Commons Lang > Issue Type: Bug > Components: lang.time.* > Environment: linux 2.6.32-28, java version "1.6.0_22" >Reporter: Christian > Fix For: 3.0, 2.7 > > > Hi, I think I found a bug in the DateUtils class in the method > isSameLocalTime. > Example: > Calendar a = Calendar.getInstance(); > a.setTimeInMillis(129736440L); > Calendar b = Calendar.getInstance(); > b.setTimeInMillis(129732120L); > Assert.assertFalse(DateUtils.isSameLocalTime(a, b)); > This is because the method compares > cal1.get(Calendar.HOUR) == cal2.get(Calendar.HOUR) > but I think it has to be > cal1.get(Calendar.HOUR_OF_DAY) == cal2.get(Calendar.HOUR_OF_DAY) > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-369) ExceptionUtils not thread-safe
[ https://issues.apache.org/jira/browse/LANG-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-369: --- Fix Version/s: (was: 2.x) 2.7 > ExceptionUtils not thread-safe > -- > > Key: LANG-369 > URL: https://issues.apache.org/jira/browse/LANG-369 > Project: Commons Lang > Issue Type: Bug > Components: lang.exception.* >Reporter: Sebb > Fix For: 3.0, 2.7 > > Attachments: LANG-369-2.patch, LANG-369.patch > > > The ExceptionUtils class does not appear to be thread-safe: > - CAUSE_METHOD_NAMES is not final, so may not be visible to all threads > - addCauseMethodName() and removeCauseMethodName() can update > CAUSE_METHOD_NAMES but are not synch. > - all accesses to CAUSE_METHOD_NAMES probably need to be synchronised > The documentation does not state whether or not the class is thread-safe, but > given that it only has static methods it does not make any sense unless it is > thread-safe. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: (was: MATH-1041_Comparator.patch) > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-771) DateUtils.ceiling does not behave correctly for dates on the boundaries
[
https://issues.apache.org/jira/browse/LANG-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796580#comment-13796580
]
Henri Yandell commented on LANG-771:
Noting as patch needed, though I think overhaul for 4.0 might be a better
phrase :)
> DateUtils.ceiling does not behave correctly for dates on the boundaries
> ---
>
> Key: LANG-771
> URL: https://issues.apache.org/jira/browse/LANG-771
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.0.1
> Environment: Windows XP Professional
> Java 1.6
>Reporter: Ryan Holmes
>Priority: Minor
> Fix For: Patch Needed
>
>
> DateUtils.ceiling does not behave as expected for dates exactly on the
> boundaries specified.
> To be consistent with the name "ceiling", it follows that if a date is
> already at its "ceiling", it should not be pushed any higher. Yet the
> current implementation (and, it would appear, all implementations since its
> creation) of DateUtils.ceiling push a value exactly on its ceiling to the
> next value.
> Observe what happens if the following tests are added to
> DateUtilsTest.testCeil():
> double double4 = 15.0;
> assertEquals("ceiling double-4 failed",
> double4,
> Math.ceil(double4));
>
> Date date4 = dateTimeParser.parse("March 30, 2003 01:10:00.000");
> assertEquals("ceiling minute-4 failed",
> date4,
> DateUtils.ceiling(date4, Calendar.MINUTE));
> The first assert passes, as Math.ceil behaves as it should (i.e.
> Mail.ceil(15.0) = 15.0).
> However, the second assert fails with:
>ceiling minute-4 failed expected: but
> was:
> as the routine incorrectly (I believe) pushes the value to the next minute.
> Either the method is incorrectly named ([as previously
> suggested|https://issues.apache.org/jira/browse/LANG-434?focusedCommentId=12855836#comment-12855836])
> or it should probably be corrected to be consistent with expected behaviour
> (using Math.ceil as a benchmark).
> If changing the behaviour of DateUtils.ceiling is perceived to have too many
> flow-on effects (e.g. backwards compatibility issues) then perhaps it should
> be renamed to DateUtils.ceil to make it consistent with the Math class method
> name and to make the change in behaviour obvious (and perhaps also have a
> DateUtils.floor as a synonym for DateUtils.truncate).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-794) SystemUtils.IS_OS_WINDOWS_2008, VISTA are incorrect
[ https://issues.apache.org/jira/browse/LANG-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-794: --- Fix Version/s: Patch Needed > SystemUtils.IS_OS_WINDOWS_2008, VISTA are incorrect > --- > > Key: LANG-794 > URL: https://issues.apache.org/jira/browse/LANG-794 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.1 > Environment: Windows Server 2008 R2, Rackspace Cloud Instance >Reporter: Tyler Hobbs > Fix For: Patch Needed > > > On Windows Server 2008 R2 (a Rackspace Cloud Instance), the values of > SystemUtils.IS_OS_WINDOWS_2008 and SystemUtils.IS_OS_WINDOWS_VISTA are > incorrect: the former is false and the latter is true. > I'm not sure how to fix the VISTA flag (as I don't have an instance to test > against), but the cause of WINDOWS_2008 being set to false is that the match > explicitly requires the version to be 6.1, where 6.0 can apparently also be > the version number for 2008 R2. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796579#comment-13796579
]
Henri Yandell commented on LANG-796:
Javadoc patch needed.
> DateUtils.addDays does not work properly with daylight saving time (DST)
>
>
> Key: LANG-796
> URL: https://issues.apache.org/jira/browse/LANG-796
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 2.6
>Reporter: Nicola Barbiero
> Fix For: Patch Needed
>
>
> DateUtils.addDays does not work properly with daylight saving time.
> The signature of the method is
> Date addDays(Date date, int amount)
> and the javadocs says "Adds a number of days to a date returning a new
> object. The original date object is unchanged",
> so if X=date.getTime() is the number of milliseconds of the date in input,
> the expected behaviour is that the returned Date has a number of milliseconds
> equal to X+amount*(8640), where 8640 is the number of milliseconds in
> one day.
> But when the calculation goes across the DST change date, the number of
> milliseconds added does not correspond to whole days.
> For example, here in Brussels, this code fragment:
>Date input = DateUtils.parseDateStrictly("25-03-2012_00:00", new String[]
> { "dd-MM-_HH:mm" });
>Date output = DateUtils.addDays(input, 1);
> will give:
> 'input' equals to "Sun Mar 25 00:00:00 CET 2012"==> input.getTime()
> equals to 133263000
> 'output' equals to "Mon Mar 26 00:00:00 CEST 2012" ==> output.getTime()
> equals to 133271280
> where 133271280-133263000=8280 < 8640
> (in fact 8280 is equivalent to 23h).
> Since addDays is working with objects Date, it should not be influenced by
> events like the DST.
> Proposed solution: replace the current implementation
> public static Date add(Date date, int calendarField, int amount) {
> if (date == null) {
> throw new IllegalArgumentException("The date must not be null");
> }
> Calendar c = Calendar.getInstance();
> c.setTime(date);
> c.add(calendarField, amount);
> return c.getTime();
> }
> based on Calendar with an implementation that works only with Date objects,
> for example:
> public static Date add(Date date, int calendarField, int amount) {
> if (date == null) {
> throw new IllegalArgumentException("The date must not be null");
> }
> return new Date(input.getTime() + amount * 8640l);
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-796:
---
Fix Version/s: Patch Needed
> DateUtils.addDays does not work properly with daylight saving time (DST)
>
>
> Key: LANG-796
> URL: https://issues.apache.org/jira/browse/LANG-796
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 2.6
>Reporter: Nicola Barbiero
> Fix For: Patch Needed
>
>
> DateUtils.addDays does not work properly with daylight saving time.
> The signature of the method is
> Date addDays(Date date, int amount)
> and the javadocs says "Adds a number of days to a date returning a new
> object. The original date object is unchanged",
> so if X=date.getTime() is the number of milliseconds of the date in input,
> the expected behaviour is that the returned Date has a number of milliseconds
> equal to X+amount*(8640), where 8640 is the number of milliseconds in
> one day.
> But when the calculation goes across the DST change date, the number of
> milliseconds added does not correspond to whole days.
> For example, here in Brussels, this code fragment:
>Date input = DateUtils.parseDateStrictly("25-03-2012_00:00", new String[]
> { "dd-MM-_HH:mm" });
>Date output = DateUtils.addDays(input, 1);
> will give:
> 'input' equals to "Sun Mar 25 00:00:00 CET 2012"==> input.getTime()
> equals to 133263000
> 'output' equals to "Mon Mar 26 00:00:00 CEST 2012" ==> output.getTime()
> equals to 133271280
> where 133271280-133263000=8280 < 8640
> (in fact 8280 is equivalent to 23h).
> Since addDays is working with objects Date, it should not be influenced by
> events like the DST.
> Proposed solution: replace the current implementation
> public static Date add(Date date, int calendarField, int amount) {
> if (date == null) {
> throw new IllegalArgumentException("The date must not be null");
> }
> Calendar c = Calendar.getInstance();
> c.setTime(date);
> c.add(calendarField, amount);
> return c.getTime();
> }
> based on Calendar with an implementation that works only with Date objects,
> for example:
> public static Date add(Date date, int calendarField, int amount) {
> if (date == null) {
> throw new IllegalArgumentException("The date must not be null");
> }
> return new Date(input.getTime() + amount * 8640l);
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-771) DateUtils.ceiling does not behave correctly for dates on the boundaries
[
https://issues.apache.org/jira/browse/LANG-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-771:
---
Fix Version/s: Patch Needed
> DateUtils.ceiling does not behave correctly for dates on the boundaries
> ---
>
> Key: LANG-771
> URL: https://issues.apache.org/jira/browse/LANG-771
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.0.1
> Environment: Windows XP Professional
> Java 1.6
>Reporter: Ryan Holmes
>Priority: Minor
> Fix For: Patch Needed
>
>
> DateUtils.ceiling does not behave as expected for dates exactly on the
> boundaries specified.
> To be consistent with the name "ceiling", it follows that if a date is
> already at its "ceiling", it should not be pushed any higher. Yet the
> current implementation (and, it would appear, all implementations since its
> creation) of DateUtils.ceiling push a value exactly on its ceiling to the
> next value.
> Observe what happens if the following tests are added to
> DateUtilsTest.testCeil():
> double double4 = 15.0;
> assertEquals("ceiling double-4 failed",
> double4,
> Math.ceil(double4));
>
> Date date4 = dateTimeParser.parse("March 30, 2003 01:10:00.000");
> assertEquals("ceiling minute-4 failed",
> date4,
> DateUtils.ceiling(date4, Calendar.MINUTE));
> The first assert passes, as Math.ceil behaves as it should (i.e.
> Mail.ceil(15.0) = 15.0).
> However, the second assert fails with:
>ceiling minute-4 failed expected: but
> was:
> as the routine incorrectly (I believe) pushes the value to the next minute.
> Either the method is incorrectly named ([as previously
> suggested|https://issues.apache.org/jira/browse/LANG-434?focusedCommentId=12855836#comment-12855836])
> or it should probably be corrected to be consistent with expected behaviour
> (using Math.ceil as a benchmark).
> If changing the behaviour of DateUtils.ceiling is perceived to have too many
> flow-on effects (e.g. backwards compatibility issues) then perhaps it should
> be renamed to DateUtils.ceil to make it consistent with the Math class method
> name and to make the change in behaviour obvious (and perhaps also have a
> DateUtils.floor as a synonym for DateUtils.truncate).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-852) Insufficient datetime pattern in FastDateParserTest
[ https://issues.apache.org/jira/browse/LANG-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-852: --- Fix Version/s: (was: Nightly Builds) > Insufficient datetime pattern in FastDateParserTest > --- > > Key: LANG-852 > URL: https://issues.apache.org/jira/browse/LANG-852 > Project: Commons Lang > Issue Type: Test > Components: lang.time.* >Reporter: nguyen phuc lam >Assignee: Charles Honton >Priority: Minor > Attachments: FastDateParserTest.diff > > > One of the test cases in FastDateParserTest is failing due to insufficient > datetime pattern. Here is the output from junit: > Testcase: testParses took 0.015 sec > FAILED > ja_JP 1940 G/y/M/d/h/a/E/Z America/New_York expected: 1940> but was: > junit.framework.AssertionFailedError: ja_JP 1940 G/y/M/d/h/a/E/Z > America/New_York expected: but was: 12:00:00 SGT 1940> > at > org.apache.commons.lang3.time.FastDateParserTest.testParses(FastDateParserTest.java:221) > To fix the failing test, it is necessary to change two date time patterns > (short and long forms) as follows: > private static final String SHORT_FORMAT_NOERA = "y/M/d/h/a/m/E/Z"; > private static final String LONG_FORMAT_NOERA = > "///////"; -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: MATH-1041_Pair.patch MATH-1041_Comparator.patch > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796576#comment-13796576 ] Sean Owen commented on MATH-1041: - Done. Yes I saw that and had updated the patch already. It's broken down into two now as well. > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-806) RandomStringUtils can enter infinite loop if chosen char does not meet letter/digit requirements
[ https://issues.apache.org/jira/browse/LANG-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-806: --- Fix Version/s: Review Patch > RandomStringUtils can enter infinite loop if chosen char does not meet > letter/digit requirements > > > Key: LANG-806 > URL: https://issues.apache.org/jira/browse/LANG-806 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 2.6, 3.1 >Reporter: Sebb > Fix For: Review Patch > > Attachments: LANG-806.patch, RandomStringException.java > > > An infinite loop can result if the selection process never returns a char > that passes the validation test. > This can occur if the subset specified by the start and end characters does > not contain any valid characters. > For example: > RandomStringUtils.random(3, 5, 10, true, true); // 1 > RandomStringUtils.random(3, 56192, 56319, false, false); // 2 > There's also the case where only surrogates are allowed, but the buffer is > not an even number of characters, for example: > RandomStringUtils.random(3, 56320, 57343, false, false); // 3 > The second example is easy to detect, but in general it does not seem easy to > determine in advance if the subset contains any valid characters - except by > evaluating all the possible char values. This would be expensive if the > subset range is large. > One possibility is to count the total number of loops (or retries), and throw > an error if it exceeds a given value. Or count the number of consecutive > retries. > In both cases the threshold value must be set high enough to allow for the > cases where the allowable char range contains only a small proportion of > valid characters. > In the case of digits only, the default allowable range is currently set to > digits + letters, so the proportion of valid chars is 10/90 i.e. approx 11%. > A minimum proportion of 1% or 0.1% would be necessary to reduce the number of > false positives. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: (was: MATH-1041.patch) > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (LANG-850) DateUtils.truncatedCompareTo not working properly with DST timezones
[
https://issues.apache.org/jira/browse/LANG-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed LANG-850.
--
Resolution: Not A Problem
Looks like this conversation was resolved :)
> DateUtils.truncatedCompareTo not working properly with DST timezones
>
>
> Key: LANG-850
> URL: https://issues.apache.org/jira/browse/LANG-850
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
> Environment: java version "1.6.0_32"
> Windows 7
> Timezone: America/Montevideo
>Reporter: Rafael Sisto
>Priority: Minor
> Labels: patch
>
> The method truncatedCompareTo doesn't work properly when comparing 2
> calendars in a different timezone (when one of them is "America/Montevideo",
> the same as the machine running the test).
> Here is the sample code to reproduce.
> The Timezone of the computer has to be set to UTC-3 Montevideo, with DST.
> {quote}
> GregorianCalendar c1 = new GregorianCalendar(2012,10,6);
> System.out.println("The time: " + c1.getTime());
> c1.setTimeZone(TimeZone.getTimeZone("America/Montevideo"));
> Calendar truncate1 = DateUtils.truncate(c1, Calendar.MONTH);
> System.out.println("America/Montevideo then truncated: " +
> truncate1.getTime());
> GregorianCalendar c2 = new GregorianCalendar(2012,10,6);
> c2.setTimeZone(TimeZone.getTimeZone("GMT"));
> Calendar truncate2 = DateUtils.truncate(c2, Calendar.MONTH);
> System.out.println("GMT then truncated: " + truncate2.getTime());
>
> System.out.println("Truncated compare: " + DateUtils.truncatedCompareTo(c1,
> c2, Calendar.MONTH));
> {quote}
> The output:
> {quote}
> The time: Tue Nov 06 00:00:00 UYST 2012
> America/Montevideo then truncated: Thu Nov 01 00:00:00 UYST 2012
> GMT then truncated: Wed Oct 31 22:00:00 UYST 2012
> Truncated compare: 1
> {quote}
> A suggestion is to change the TimeZone of both calendars before truncating.
> For example, setting both to TimeZone.getDefault().
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-821) Support OS X versions in SystemUtils
[ https://issues.apache.org/jira/browse/LANG-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-821: --- Fix Version/s: Patch Needed > Support OS X versions in SystemUtils > > > Key: LANG-821 > URL: https://issues.apache.org/jira/browse/LANG-821 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 3.1 >Reporter: Henri Yandell > Fix For: Patch Needed > > > We support different versions of Windows; why not OS X? > See: > http://www.milesdennis.com/2010/05/detecting-which-os-is-running-in-java.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796567#comment-13796567 ] Gilles commented on MATH-1041: -- I've already committed some changes, one at a time. Sorry if I've been to fast. :) Could you please update your working copy, and provide further changes in separate patches? E.g. it would be nice to have one patch for the comparator code and unit tests. > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-842) Lack of consistency in comparaison api
[ https://issues.apache.org/jira/browse/LANG-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796569#comment-13796569 ] Henri Yandell commented on LANG-842: Fair point. My gut is that we have other methods for which null in leads to null out other than where dictated by the JDK APIs. I could be wrong though :) Primarily I didn't see anything much to do here, but wanted to make a note to consider it in a future date subpackage rewrite. > Lack of consistency in comparaison api > -- > > Key: LANG-842 > URL: https://issues.apache.org/jira/browse/LANG-842 > Project: Commons Lang > Issue Type: Improvement > Components: lang.*, lang.time.* >Affects Versions: 3.2 >Reporter: Pier-Luc Caron St-Pierre >Priority: Trivial > > The comparaison api is lacking of consistency with null. > Few instances : > org.apache.commons.lang3.StringUtils#equals returns false if one of the > parameter is null. > org.apache.commons.lang3.ObjectUtils#equals returns false if one of the > parameter is null. > org.apache.commons.lang3.time.DateUtils#truncatedCompareTo throws > IllegalArgumentException if one of the parameter is null > org.apache.commons.lang3.time.DateUtils#isSameInstant throws > IllegalArgumentException if one of the parameter is null > I do not have any suggestion to fix that problem because any solution would > break backward compatibility. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Description: I use Commons Math heavily, and have adopted its Pair class for the cases where I need, well, a pair of things. The attached patch adds three small improvements to the Pair class: - toString() method - factory method ".create()" to avoid duplicating generic types on instance creation - a Comparator Tests are included. I won't feel offended if this is rejected or modified but just wanted to supply the suggestion. was: I use Commons Math heavily, and have adopted its Pair class for the cases where I need, well, a pair of things. The attached patch adds three small improvements to the Pair class: - toString() method - factory method ".of()" to avoid duplicating generic types on instance creation - a Comparator Tests are included. I won't feel offended if this is rejected or modified but just wanted to supply the suggestion. > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (LANG-809) Encapsulate trival equal test into a method to avoid repeating over and over.....
[
https://issues.apache.org/jira/browse/LANG-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed LANG-809.
--
Resolution: Won't Fix
Closing as won't fix per Duncan's comment.
> Encapsulate trival equal test into a method to avoid repeating over and
> over.
> -
>
> Key: LANG-809
> URL: https://issues.apache.org/jira/browse/LANG-809
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.builder.*
>Affects Versions: 3.1
> Environment: Windows 7
>Reporter: Colbert Philippe
>Priority: Minor
> Labels: Encapsulate, EqualsBuilder, in, test, trivial
>
> In class EqualsBuilder, the documentation gives sample code on how to use
> EqualsBuilder. The proper usage of class EqualsBuilder is a bit long. My
> suggestion is to encapsulate the following trivial test into a method inside
> the class EqualsBuilder. You call it the new method trivalTest(Object obj1,
> Object obj2).
>// This is the code that should be put in a method to avoid repeating
>if (obj == null) { return false; }
>if (obj == this) { return true; }
>if (obj.getClass() != getClass()) {
> return false;
>}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-833) ToStringBuilder should use StringBuilder
[ https://issues.apache.org/jira/browse/LANG-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-833: --- Fix Version/s: Patch Needed > ToStringBuilder should use StringBuilder > > > Key: LANG-833 > URL: https://issues.apache.org/jira/browse/LANG-833 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 3.1 >Reporter: Shevek > Fix For: Patch Needed > > > Rewriting as lang3 but still using StringBuffer (synchronized) looks like a > missed opportunity. Please use StringBuilder. > Suggest audit for uses of StringBuffer in lang3 overall. No cause for it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: (was: MATH-1041.patch) > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".of()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: MATH-1041.patch > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".of()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-779) Provide a StrBuilder-based or StringBuilder-based ToStringBuilder
[ https://issues.apache.org/jira/browse/LANG-779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-779: --- Fix Version/s: Patch Needed > Provide a StrBuilder-based or StringBuilder-based ToStringBuilder > - > > Key: LANG-779 > URL: https://issues.apache.org/jira/browse/LANG-779 > Project: Commons Lang > Issue Type: Improvement > Components: lang.builder.* >Affects Versions: 3.1 >Reporter: Simon Dierl >Priority: Minor > Fix For: Patch Needed > > > At the moment, ToStringBuilder internally uses a StringBuffer to create the > output String. StringBuffer, as opposed to StringBuilder and StrBuilder, is > synchronized. Since ToStringBuilder will almost never leave the > toString()-method, the synchronization only adds overhead. > Since the ToStringBuilder API never suggests that ToStringBuilder is > thread-safe, either the current implementation could be changed to use > Str[ing]Builder or an alternative implementation could be provided. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-768) Test jar has the same manifest as production jar
[ https://issues.apache.org/jira/browse/LANG-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-768: --- Fix Version/s: Patch Needed > Test jar has the same manifest as production jar > > > Key: LANG-768 > URL: https://issues.apache.org/jira/browse/LANG-768 > Project: Commons Lang > Issue Type: Improvement > Components: General >Affects Versions: 3.0.1 >Reporter: Oliver Heger >Priority: Minor > Fix For: Patch Needed > > > At least attributes referring to the name of the artifact should be different > to be more consistent and avoid confusion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-768) Test jar has the same manifest as production jar
[ https://issues.apache.org/jira/browse/LANG-768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796562#comment-13796562 ] Henri Yandell commented on LANG-768: Seems fair. Patch needed. > Test jar has the same manifest as production jar > > > Key: LANG-768 > URL: https://issues.apache.org/jira/browse/LANG-768 > Project: Commons Lang > Issue Type: Improvement > Components: General >Affects Versions: 3.0.1 >Reporter: Oliver Heger >Priority: Minor > Fix For: Patch Needed > > > At least attributes referring to the name of the artifact should be different > to be more consistent and avoid confusion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-915) Wrong locale handling in LocaleUtils.toLocale()
[ https://issues.apache.org/jira/browse/LANG-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-915: --- Fix Version/s: Patch Needed > Wrong locale handling in LocaleUtils.toLocale() > --- > > Key: LANG-915 > URL: https://issues.apache.org/jira/browse/LANG-915 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 3.1 >Reporter: Sergio Fernández >Priority: Minor > Fix For: Patch Needed > > > The static method LocaleUtils.toLocale() fails, at least, to parse 3-char > locale strings, which are completelly valid BCP47 locales. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1039) Logarithmic probability and density calculations for the distributions
[ https://issues.apache.org/jira/browse/MATH-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796558#comment-13796558 ] Aleksei Dievskii commented on MATH-1039: 2.14.1, though I don't think that they changed these functions in the next release. > Logarithmic probability and density calculations for the distributions > -- > > Key: MATH-1039 > URL: https://issues.apache.org/jira/browse/MATH-1039 > Project: Commons Math > Issue Type: New Feature >Reporter: Aleksei Dievskii >Priority: Minor > Labels: features, patch > Attachments: LOGDENSITY.patch > > > A person working with fairly small probabilities and densities often employs > their logarithms to increase precision and decrease the chance of an > underflow. However, just taking a log of the probability() or density() > return value doesn't necessarily solve the problem, as these methods > themselves could have lost precision or underflowed. This patch introduces > new logProbability() and logDensity() methods overriden for many relevant > distribution. The patch also introduces tests of these new methods. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (LANG-902) RandomStringUtils.random (count, letters=true, number=true) may not use numerics
[ https://issues.apache.org/jira/browse/LANG-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-902. -- Resolution: Fixed Fix Version/s: 3.2 Clarified in the documentation (changed to 'may'). Thanks for pointing that out. > RandomStringUtils.random (count, letters=true, number=true) may not use > numerics > > > Key: LANG-902 > URL: https://issues.apache.org/jira/browse/LANG-902 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.1 >Reporter: Andrzej Winnicki >Priority: Minor > Labels: random > Fix For: 3.2 > > > Either there is a bug in an implementation or misunderstanding in docs. > RandomStringUtils.random (count, letters, numbers) is documented so that: > letters if true, generated string *will* include alphabetic characters > numbers if true, generated string *will* include numeric characters > But apparently the current implementation supports only that generated string > *may* include either only letters, only numbers or both. > This is current implementation: > if (letters && Character.isLetter(ch) || numbers && Character.isDigit(ch) || > !letters && !numbers) > So there may be situation when generated string is not containing numbers at > all which is in contrary with what the docs say. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-842) Lack of consistency in comparaison api
[ https://issues.apache.org/jira/browse/LANG-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796556#comment-13796556 ] Duncan Jones commented on LANG-842: --- I'm not convinced there is any inconsistency. Or at least, not in the examples presented by the reporter. Henri - can you explain what you think is inconsistent? > Lack of consistency in comparaison api > -- > > Key: LANG-842 > URL: https://issues.apache.org/jira/browse/LANG-842 > Project: Commons Lang > Issue Type: Improvement > Components: lang.*, lang.time.* >Affects Versions: 3.2 >Reporter: Pier-Luc Caron St-Pierre >Priority: Trivial > > The comparaison api is lacking of consistency with null. > Few instances : > org.apache.commons.lang3.StringUtils#equals returns false if one of the > parameter is null. > org.apache.commons.lang3.ObjectUtils#equals returns false if one of the > parameter is null. > org.apache.commons.lang3.time.DateUtils#truncatedCompareTo throws > IllegalArgumentException if one of the parameter is null > org.apache.commons.lang3.time.DateUtils#isSameInstant throws > IllegalArgumentException if one of the parameter is null > I do not have any suggestion to fix that problem because any solution would > break backward compatibility. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: MATH-1041.patch Updated patch per Phil's comments on the mailing list. > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".of()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: (was: MATH-1041.patch) > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".of()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-923) JDK 1.8 Changes
[ https://issues.apache.org/jira/browse/LANG-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796542#comment-13796542 ] Henri Yandell commented on LANG-923: If a new date time API shows, we should overhaul our time package. Note that LANG-842 points out our time package's handling of null is inconsistent with the rest of Lang. We should fix that. > JDK 1.8 Changes > --- > > Key: LANG-923 > URL: https://issues.apache.org/jira/browse/LANG-923 > Project: Commons Lang > Issue Type: Bug >Reporter: Henri Yandell > Fix For: 4.0 > > > Omnibus issue to cover any JDK 1.8 related changes. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (LANG-842) Lack of consistency in comparaison api
[ https://issues.apache.org/jira/browse/LANG-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-842. -- Resolution: Won't Fix Resolving per the above. I've noted the inconsistency in a JDK 1.8 related issue for an overhaul of the date code: LANG-923 > Lack of consistency in comparaison api > -- > > Key: LANG-842 > URL: https://issues.apache.org/jira/browse/LANG-842 > Project: Commons Lang > Issue Type: Improvement > Components: lang.*, lang.time.* >Affects Versions: 3.2 >Reporter: Pier-Luc Caron St-Pierre >Priority: Trivial > > The comparaison api is lacking of consistency with null. > Few instances : > org.apache.commons.lang3.StringUtils#equals returns false if one of the > parameter is null. > org.apache.commons.lang3.ObjectUtils#equals returns false if one of the > parameter is null. > org.apache.commons.lang3.time.DateUtils#truncatedCompareTo throws > IllegalArgumentException if one of the parameter is null > org.apache.commons.lang3.time.DateUtils#isSameInstant throws > IllegalArgumentException if one of the parameter is null > I do not have any suggestion to fix that problem because any solution would > break backward compatibility. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (LANG-923) JDK 1.8 Changes
Henri Yandell created LANG-923: -- Summary: JDK 1.8 Changes Key: LANG-923 URL: https://issues.apache.org/jira/browse/LANG-923 Project: Commons Lang Issue Type: Bug Reporter: Henri Yandell Fix For: 4.0 Omnibus issue to cover any JDK 1.8 related changes. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-860) String split with an escape pattern
[
https://issues.apache.org/jira/browse/LANG-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796540#comment-13796540
]
Henri Yandell commented on LANG-860:
Agreed that this is in the scope of CSV, or a better CSV, rather than Lang.
> String split with an escape pattern
> ---
>
> Key: LANG-860
> URL: https://issues.apache.org/jira/browse/LANG-860
> Project: Commons Lang
> Issue Type: Improvement
> Components: Parser
>Reporter: Michael Knapp
>Priority: Minor
> Labels: patch, split
> Attachments: StringUtilsSplitEscapingly.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Often times there are strings which are delimited, but certain patterns can
> escape the delimiter. For example, quotes are used in CSV to escape a comma
> delimiter. I have written a couple methods for StringUtils that split
> strings while considering the possibility of an escape pattern. For example,
> when given "a,\"b,c\",c", it will produce {"a","\"b,c\"","c"}. In my code,
> the delimiter can be a string, and it can be escaped by any regular
> expression pattern. Unit tests are already written and passing.
> I plan to attach the patch for this once the ticket is created. I just need
> a committer to review the patch, approve, and commit it for me.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Moved] (CSV-101) String split with an escape pattern
[
https://issues.apache.org/jira/browse/CSV-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell moved LANG-860 to CSV-101:
Component/s: (was: lang.*)
Parser
Workflow: classic default workflow (was: Default workflow, editable
Closed status)
Key: CSV-101 (was: LANG-860)
Project: Commons CSV (was: Commons Lang)
> String split with an escape pattern
> ---
>
> Key: CSV-101
> URL: https://issues.apache.org/jira/browse/CSV-101
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Reporter: Michael Knapp
>Priority: Minor
> Labels: patch, split
> Attachments: StringUtilsSplitEscapingly.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Often times there are strings which are delimited, but certain patterns can
> escape the delimiter. For example, quotes are used in CSV to escape a comma
> delimiter. I have written a couple methods for StringUtils that split
> strings while considering the possibility of an escape pattern. For example,
> when given "a,\"b,c\",c", it will produce {"a","\"b,c\"","c"}. In my code,
> the delimiter can be a string, and it can be escaped by any regular
> expression pattern. Unit tests are already written and passing.
> I plan to attach the patch for this once the ticket is created. I just need
> a committer to review the patch, approve, and commit it for me.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-867) StrSubstitutor: Ability to turn off substitution in values
[
https://issues.apache.org/jira/browse/LANG-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796537#comment-13796537
]
Henri Yandell commented on LANG-867:
Seems fair to me. Patch needed.
> StrSubstitutor: Ability to turn off substitution in values
> --
>
> Key: LANG-867
> URL: https://issues.apache.org/jira/browse/LANG-867
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.text.*
>Reporter: Arend v. Reinersdorff
>Priority: Minor
> Labels: features
> Fix For: Patch Needed
>
>
> In StrSubstitutor variable replacement works in a recursive way. And
> currently there's no way to turn this off.
> Why turn it off: I want to replace some variables in a simple template. Some
> of the replacemnt values are arbitrary user input.
> At the moment I escape all dollar signs in the replacement values with "$$".
> This is annoying. Especially as I use one template with variables as a value
> for another variable. Here I have to escape twice.
> Here's some example code. At the moment it prints "Hello world". The
> commented line is my suggestion for this feature. If it works, it should
> print "Hello ${key2}":
> Map valueMap = new HashMap<>();
> valueMap.put("key", "$${key2}");
> valueMap.put("key2", "world");
> String source = "Hello ${key}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-867) StrSubstitutor: Ability to turn off substitution in values
[
https://issues.apache.org/jira/browse/LANG-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-867:
---
Fix Version/s: Patch Needed
> StrSubstitutor: Ability to turn off substitution in values
> --
>
> Key: LANG-867
> URL: https://issues.apache.org/jira/browse/LANG-867
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.text.*
>Reporter: Arend v. Reinersdorff
>Priority: Minor
> Labels: features
> Fix For: Patch Needed
>
>
> In StrSubstitutor variable replacement works in a recursive way. And
> currently there's no way to turn this off.
> Why turn it off: I want to replace some variables in a simple template. Some
> of the replacemnt values are arbitrary user input.
> At the moment I escape all dollar signs in the replacement values with "$$".
> This is annoying. Especially as I use one template with variables as a value
> for another variable. Here I have to escape twice.
> Here's some example code. At the moment it prints "Hello world". The
> commented line is my suggestion for this feature. If it works, it should
> print "Hello ${key2}":
> Map valueMap = new HashMap<>();
> valueMap.put("key", "$${key2}");
> valueMap.put("key2", "world");
> String source = "Hello ${key}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (LANG-869) add randomXMLText
[
https://issues.apache.org/jira/browse/LANG-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed LANG-869.
--
Resolution: Won't Fix
Resolving as won't fix per my previous comment. I don't think there's a good
generic function in here. Please feel free to reopen with a patch if you think
you've got something.
> add randomXMLText
> -
>
> Key: LANG-869
> URL: https://issues.apache.org/jira/browse/LANG-869
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Reporter: Jin Kwon
>Priority: Trivial
> Labels: random
>
> Please add some random method for values of XML elements or attributes.
> I tried RandomStringUtils#random() for XML tag values and got
> {{An invalid XML character (Unicode: 0x11) was found in the element content
> of the document.}}
> #randomAxxx and #randomNxxx may not enough.
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-903) Add XML implementation of ToStringStyle
[ https://issues.apache.org/jira/browse/LANG-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796534#comment-13796534 ] Henri Yandell commented on LANG-903: Marked as patch needed, though I don't focus on the builder package so not sure if this is a good add or not. My main concern is that it shouldn't add dependencies, yet needs to be maintainable. > Add XML implementation of ToStringStyle > --- > > Key: LANG-903 > URL: https://issues.apache.org/jira/browse/LANG-903 > Project: Commons Lang > Issue Type: Improvement > Components: lang.builder.* >Affects Versions: 3.1 >Reporter: Dave Hughes >Priority: Minor > Fix For: Patch Needed > > Original Estimate: 24h > Remaining Estimate: 24h > > Lang 1.1 included a commented out implementation of XMLToStringStyle. This > disappeared in later versions, but is a very useful implementation. > (JSONToStringStyle would also be very nice) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-903) Add XML implementation of ToStringStyle
[ https://issues.apache.org/jira/browse/LANG-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-903: --- Fix Version/s: Patch Needed > Add XML implementation of ToStringStyle > --- > > Key: LANG-903 > URL: https://issues.apache.org/jira/browse/LANG-903 > Project: Commons Lang > Issue Type: Improvement > Components: lang.builder.* >Affects Versions: 3.1 >Reporter: Dave Hughes >Priority: Minor > Fix For: Patch Needed > > Original Estimate: 24h > Remaining Estimate: 24h > > Lang 1.1 included a commented out implementation of XMLToStringStyle. This > disappeared in later versions, but is a very useful implementation. > (JSONToStringStyle would also be very nice) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (LANG-790) Null safe Navigation in ObjectUtils
[ https://issues.apache.org/jira/browse/LANG-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-790. -- Resolution: Won't Fix Closing this issue out. I think it's a request for a better EL (or beanutils or ...). > Null safe Navigation in ObjectUtils > --- > > Key: LANG-790 > URL: https://issues.apache.org/jira/browse/LANG-790 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Reporter: Gokul Nanthakumar C > > Adding a method for null safe navigation of objects will be very helpful. for > example a method like > ObjectUtils.getValue(Object obj, String "path", String defaultValue); > ex :ObjectUtils.getValue(myObject, "x.y.z", "default"); > it will navigate in the myObject like myObject.getX().getY().getZ(), if any > thing in the path is null (x,y or z), it will return the default value. > It will be really useful, it is like null safe navigation in groovy. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-863) Method returns number of inheritance hops between parent and subclass
[
https://issues.apache.org/jira/browse/LANG-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796525#comment-13796525
]
Henri Yandell commented on LANG-863:
Patch needed.
> Method returns number of inheritance hops between parent and subclass
> -
>
> Key: LANG-863
> URL: https://issues.apache.org/jira/browse/LANG-863
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.reflect.*
>Reporter: Daneel S. Yaitskov
> Fix For: Patch Needed
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> For example.
> class A {
> }
> class B extends A {
> }
> class C extends B {
> }
> int d;
> d = InheritanceUtils.distance(A.class, A.class);
> Assert.assertEquals(0, d);
> d = InheritanceUtils.distance(B.class, A.class);
> Assert.assertEquals(1, d);
> d = InheritanceUtils.distance(C.class, A.class);
> Assert.assertEquals(2, d);
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-863) Method returns number of inheritance hops between parent and subclass
[
https://issues.apache.org/jira/browse/LANG-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-863:
---
Fix Version/s: Patch Needed
> Method returns number of inheritance hops between parent and subclass
> -
>
> Key: LANG-863
> URL: https://issues.apache.org/jira/browse/LANG-863
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.reflect.*
>Reporter: Daneel S. Yaitskov
> Fix For: Patch Needed
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> For example.
> class A {
> }
> class B extends A {
> }
> class C extends B {
> }
> int d;
> d = InheritanceUtils.distance(A.class, A.class);
> Assert.assertEquals(0, d);
> d = InheritanceUtils.distance(B.class, A.class);
> Assert.assertEquals(1, d);
> d = InheritanceUtils.distance(C.class, A.class);
> Assert.assertEquals(2, d);
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (IO-400) IOUtils: add support for copying from large byte buffers
[
https://issues.apache.org/jira/browse/IO-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796523#comment-13796523
]
Henri Yandell commented on IO-400:
--
Moved over from Lang. I think this was in the wrong project.
> IOUtils: add support for copying from large byte buffers
>
>
> Key: IO-400
> URL: https://issues.apache.org/jira/browse/IO-400
> Project: Commons IO
> Issue Type: New Feature
>Reporter: Sebb
>
> Trying to write a large byte array to a FileOutputStream may cause OOME.
> This is because such output requires the use of native code, and native code
> may need to copy the array in order to access it safely, see:
> http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html#wp1265
> It might therefore be useful to have a method which writes from the byte
> array in chunks. One can create a ByteArrayInputStream from the input, and
> then use one of the copy() methods, but that creates an unnecessary array
> buffer (albeit only 4k).
> There are already write methods which copy byte[] to OutputStream and char[]
> to Writer.
> Some or all of these could be converted to use chunked output, or there could
> be new methods to implement the chunking.
> Here is a sample implementation of a stand-alone method:
> {code}
> public static void writeChunked(byte[] data, OutputStream output) throws
> IOException {
> int bytes = data.length;
> int offset = 0;
> while(bytes > 0) {
> int chunk = Math.min(bytes, DEFAULT_BUFFER_SIZE);
> output.write(data, offset, chunk);
> bytes -= chunk;
> offset += chunk;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Moved] (IO-400) IOUtils: add support for copying from large byte buffers
[
https://issues.apache.org/jira/browse/IO-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell moved LANG-897 to IO-400:
---
Affects Version/s: (was: 3.1)
Key: IO-400 (was: LANG-897)
Project: Commons IO (was: Commons Lang)
> IOUtils: add support for copying from large byte buffers
>
>
> Key: IO-400
> URL: https://issues.apache.org/jira/browse/IO-400
> Project: Commons IO
> Issue Type: New Feature
>Reporter: Sebb
>
> Trying to write a large byte array to a FileOutputStream may cause OOME.
> This is because such output requires the use of native code, and native code
> may need to copy the array in order to access it safely, see:
> http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html#wp1265
> It might therefore be useful to have a method which writes from the byte
> array in chunks. One can create a ByteArrayInputStream from the input, and
> then use one of the copy() methods, but that creates an unnecessary array
> buffer (albeit only 4k).
> There are already write methods which copy byte[] to OutputStream and char[]
> to Writer.
> Some or all of these could be converted to use chunked output, or there could
> be new methods to implement the chunking.
> Here is a sample implementation of a stand-alone method:
> {code}
> public static void writeChunked(byte[] data, OutputStream output) throws
> IOException {
> int bytes = data.length;
> int offset = 0;
> while(bytes > 0) {
> int chunk = Math.min(bytes, DEFAULT_BUFFER_SIZE);
> output.write(data, offset, chunk);
> bytes -= chunk;
> offset += chunk;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-922) Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...)
[
https://issues.apache.org/jira/browse/LANG-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796519#comment-13796519
]
Henri Yandell commented on LANG-922:
Feels like the new method is a more general Array one. Not sure if we have it
already.
ArrayUtils.countMatching(array, value) == 1
Note also that 'isOneTrue' doesn't mean the same as 'isOnlyOneTrue'. It's not
very specific and arguably would be true for {true, true, false}.
> Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of
> BooleanUtils.xor(booleans...)
>
>
> Key: LANG-922
> URL: https://issues.apache.org/jira/browse/LANG-922
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
> Fix For: 3.2
>
>
> The old implementation (prior to r1532476) of BooleanUtils.xor(boolean...)
> checked if the provided array contained exactly one boolean with value true.
> This was changed because it is not the correct behavior for an XOR operation.
> To preserve the behavior we should add BooleanUtils.isOneTrue(boolean...) and
> BooleanUtils.isOneTrue(Boolean...) (and possibly the equivalents for
> isOneFalse).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (MATH-1042) StatUtils supports int[]
[
https://issues.apache.org/jira/browse/MATH-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-1042:
-
Issue Type: Wish (was: Improvement)
Unless I'm mistaken, this is not as simple as it seems: the utilities in
{{StatUtils}} are syntactic sugar to a whole sets of classes and interfaces
that operate on {{double[]}}. So, this wold require a lot of code writing
(assuming that we'd just duplicate in order to handle {{int[]}}, which should
not be done without more thinking, IMO).
The first thing is perhaps to figure out whether your use cases specifically
require {{int[]}}, or the approximation with {{double[]}} is sufficient.
You should probably start a discussion on the "dev" ML.
> StatUtils supports int[]
>
>
> Key: MATH-1042
> URL: https://issues.apache.org/jira/browse/MATH-1042
> Project: Commons Math
> Issue Type: Wish
>Reporter: Karl Yang
>Priority: Minor
>
> Sometimes we want to find the min value, max value, percentile in a int[],
> but the StatUtils only support double[], we need to convert int[] to double[].
--
This message was sent by Atlassian JIRA
(v6.1#6144)
