Re: [GitHub] commons-lang issue #286: LANG-1352 EnumUtils.getEnumIgnoreCase and isValidEn...

[Gary Gregory]

Good ones! I can use that!

Gary

On Fri, Jan 12, 2018 at 10:00 AM, PascalSchumacher 
wrote:

> Github user PascalSchumacher commented on the issue:
>
> https://github.com/apache/commons-lang/pull/286
>
> Thanks! 
>
>
> ---
>

[jira] [Resolved] (LANG-1372) Add ToStringSummary annotation

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved LANG-1372.
-
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 3.8

> Add ToStringSummary annotation
> --
>
> Key: LANG-1372
> URL: https://issues.apache.org/jira/browse/LANG-1372
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.builder.*
>Affects Versions: 3.7
>Reporter: Sérgio Ozaki
>Assignee: Pascal Schumacher
>Priority: Trivial
> Fix For: 3.8
>
>
> Add @ToStringSummary annotation for fields you may wish not to display full 
> description.
> It is useful for fields which are too large or contains sensitive 
> information. 
> https://github.com/apache/commons-lang/pull/281



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LANG-1372) Add ToStringSummary annotation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324266#comment-16324266
 ] 

ASF GitHub Bot commented on LANG-1372:
--

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/281
  
Thanks!  


> Add ToStringSummary annotation
> --
>
> Key: LANG-1372
> URL: https://issues.apache.org/jira/browse/LANG-1372
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.builder.*
>Affects Versions: 3.7
>Reporter: Sérgio Ozaki
>Priority: Trivial
>
> Add @ToStringSummary annotation for fields you may wish not to display full 
> description.
> It is useful for fields which are too large or contains sensitive 
> information. 
> https://github.com/apache/commons-lang/pull/281



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LANG-1372) Add ToStringSummary annotation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324267#comment-16324267
 ] 

ASF GitHub Bot commented on LANG-1372:
--

Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/281


> Add ToStringSummary annotation
> --
>
> Key: LANG-1372
> URL: https://issues.apache.org/jira/browse/LANG-1372
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.builder.*
>Affects Versions: 3.7
>Reporter: Sérgio Ozaki
>Priority: Trivial
>
> Add @ToStringSummary annotation for fields you may wish not to display full 
> description.
> It is useful for fields which are too large or contains sensitive 
> information. 
> https://github.com/apache/commons-lang/pull/281



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang pull request #281: LANG-1372: Add ToStringSummary annotation

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/281


---

[GitHub] commons-lang issue #281: LANG-1372: Add ToStringSummary annotation

[PascalSchumacher]

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/281
  
Thanks! 👍 


---

[GitHub] commons-lang issue #294: Added indexesOf method

[garydgregory]

Github user garydgregory commented on the issue:

https://github.com/apache/commons-lang/pull/294
  
The question here is whether to use the more grammatically correct 
"indices" or the more casual "indexes".


---

[GitHub] commons-lang pull request #273: add lastIndexOfAnyChar method just like inde...

[garydgregory]

Github user garydgregory commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/273#discussion_r161278859
  
--- Diff: src/main/java/org/apache/commons/lang3/StringUtils.java ---
@@ -2122,6 +2122,81 @@ public static int indexOfAny(final CharSequence cs, 
final String searchChars) {
 return indexOfAny(cs, searchChars.toCharArray());
 }
 
+/**
+ * Search a CharSequence to find the last index of any
--- End diff --

Use the active voice in Javadoc: "Returns...", "Searches...", "Gets..." and 
so on.


---

[GitHub] commons-lang pull request #273: add lastIndexOfAnyChar method just like inde...

[garydgregory]

Github user garydgregory commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/273#discussion_r161279018
  
--- Diff: 
src/test/java/org/apache/commons/lang3/StringUtilsEqualsIndexOfTest.java ---
@@ -379,6 +379,44 @@ public void testIndexOfAny_StringCharArray() {
 assertEquals(-1, StringUtils.indexOfAny("ab", 'z'));
 }
 
+@Test
+public void testLastIndexOfAny_StringCharArray() {
+assertEquals(-1, StringUtils.lastIndexOfAnyChar(null, (char[]) 
null));
--- End diff --

Maybe use INDEX_NOT_FOUND as a static import instead of -1...


---

[GitHub] commons-lang pull request #273: add lastIndexOfAnyChar method just like inde...

[garydgregory]

Github user garydgregory commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/273#discussion_r161278687
  
--- Diff: src/main/java/org/apache/commons/lang3/StringUtils.java ---
@@ -2122,6 +2122,81 @@ public static int indexOfAny(final CharSequence cs, 
final String searchChars) {
 return indexOfAny(cs, searchChars.toCharArray());
 }
 
+/**
+ * Search a CharSequence to find the last index of any
+ * character in the given set of characters.
+ *
+ * A {@code null} String will return {@code -1}.
+ * A {@code null} search string will return {@code -1}.
+ *
+ * 
+ * StringUtils.lastIndexOfAnyChar(null, *)= -1
+ * StringUtils.lastIndexOfAnyChar("", *)  = -1
+ * StringUtils.lastIndexOfAnyChar(*, null)= -1
+ * StringUtils.lastIndexOfAnyChar(*, "")  = -1
+ * StringUtils.lastIndexOfAnyChar("zzabyycdxx", "za") = 2
+ * StringUtils.lastIndexOfAnyChar("zzabyycdxx", "by") = 5
+ * StringUtils.lastIndexOfAnyChar("ab", 'a')  = 0
+ * StringUtils.lastIndexOfAnyChar("ab", 'b')  = 1
+ * StringUtils.lastIndexOfAnyChar("aba","z")  = -1
+ * 
+ *
+ * @param cs  the CharSequence to check, may be null
+ * @param searchChars  the chars to search for, may be null
+ * @return the last index of any of the chars, -1 if no match or null 
input
+ */
+ public static int lastIndexOfAnyChar( final CharSequence cs,final 
String searchChars) {
+return searchChars == null ? INDEX_NOT_FOUND : 
lastIndexOfAnyChar(cs,searchChars.toCharArray());
+}
+
+   /**
+ * Search a CharSequence to find the last index of any
+ * character in the given set of characters.
+ *
+ * A {@code null} String will return {@code -1}.
+ * A {@code null} or zero length search array will return {@code 
-1}.
+ *
+ * 
+ * StringUtils.lastIndexOfAnyChar(null, *)= -1
+ * StringUtils.lastIndexOfAnyChar("", *)  = -1
+ * StringUtils.lastIndexOfAnyChar(*, null)= -1
+ * StringUtils.lastIndexOfAnyChar(*, [])  = -1
+ * StringUtils.lastIndexOfAnyChar("zzabyycdxx",['z','a']) = 2
+ * StringUtils.lastIndexOfAnyChar("zzabyycdxx",['b','y']) = 5
+ * StringUtils.lastIndexOfAnyChar("aba", ['z'])   = -1
+ * 
+ *
+ * @param cs  the CharSequence to check, may be null
+ * @param searchChars  the chars to search for, may be null
+ * @return the last index of any of the chars, -1 if no match or null 
input
+ */
+public static int lastIndexOfAnyChar( final CharSequence cs,final 
char... searchChars) {
--- End diff --

Fix formatting.


---

[GitHub] commons-lang pull request #278: Lang-1345 Enhance non-empty strings

[garydgregory]

Github user garydgregory commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/278#discussion_r161277512
  
--- Diff: src/main/java/org/apache/commons/lang3/StringUtils.java ---
@@ -7429,6 +7429,55 @@ public static String defaultString(final String str, 
final String defaultStr) {
 return isEmpty(str) ? defaultStr : str;
 }
 
+// Extensions
+
//---
+
+/**
+ * Returns either the passed in String with the specified prefix 
and suffix attached,
+ * or if the String is whitespace, empty ("") or {@code null}, an 
empty string.
+ *
+ * Whitespace is defined by {@link 
Character#isWhitespace(char)}.
+ *
+ * 
+ * StringUtils.extendIfNotBlank(null, "pre-", "-post")  = ""
+ * StringUtils.extendIfNotBlank("", "pre-", "-post")= ""
+ * StringUtils.extendIfNotBlank(" ", "pre-", "-post")   = ""
+ * StringUtils.extendIfNotBlank("bat", "pre-", "-post") = 
"pre-bat-bost"
+ * StringUtils.extendIfNotBlank("bat", null, "-post")  = "bat-post"
+ * StringUtils.extendIfNotBlank("bat", "pre-", null)  = "pre-bat"
+ * 
+ * @param str the String to check, may be null
+ * @param prefix  the string to prepend if not blank. Null will be 
converted to empty string.
+ * @param suffix  the string to append if not blank. Null will be 
converted to empty string.
+ * @return the passed in String with prefix and suffix added, or empty 
string
+ * @see StringUtils#defaultString(String, String)
+ */
+public static String extendIfNotBlank(final String str, final String 
prefix, final String suffix) {
+return isBlank(str) ? "" : defaultString(prefix) + str + 
defaultString(suffix);
--- End diff --

Reuse the EMPTY constant.


---

[GitHub] commons-lang pull request #278: Lang-1345 Enhance non-empty strings

[garydgregory]

Github user garydgregory commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/278#discussion_r161277531
  
--- Diff: src/main/java/org/apache/commons/lang3/StringUtils.java ---
@@ -7429,6 +7429,55 @@ public static String defaultString(final String str, 
final String defaultStr) {
 return isEmpty(str) ? defaultStr : str;
 }
 
+// Extensions
+
//---
+
+/**
+ * Returns either the passed in String with the specified prefix 
and suffix attached,
+ * or if the String is whitespace, empty ("") or {@code null}, an 
empty string.
+ *
+ * Whitespace is defined by {@link 
Character#isWhitespace(char)}.
+ *
+ * 
+ * StringUtils.extendIfNotBlank(null, "pre-", "-post")  = ""
+ * StringUtils.extendIfNotBlank("", "pre-", "-post")= ""
+ * StringUtils.extendIfNotBlank(" ", "pre-", "-post")   = ""
+ * StringUtils.extendIfNotBlank("bat", "pre-", "-post") = 
"pre-bat-bost"
+ * StringUtils.extendIfNotBlank("bat", null, "-post")  = "bat-post"
+ * StringUtils.extendIfNotBlank("bat", "pre-", null)  = "pre-bat"
+ * 
+ * @param str the String to check, may be null
+ * @param prefix  the string to prepend if not blank. Null will be 
converted to empty string.
+ * @param suffix  the string to append if not blank. Null will be 
converted to empty string.
+ * @return the passed in String with prefix and suffix added, or empty 
string
+ * @see StringUtils#defaultString(String, String)
+ */
+public static String extendIfNotBlank(final String str, final String 
prefix, final String suffix) {
+return isBlank(str) ? "" : defaultString(prefix) + str + 
defaultString(suffix);
+}
+
+/**
+ * Returns either the passed in String with the specified prefix 
and suffix attached,
+ * or if the String is empty ("") or {@code null}, an empty string.
+ *
+ * 
+ * StringUtils.extendIfNotEmpty(null, "pre-", "-post")  = ""
+ * StringUtils.extendIfNotEmpty("", "pre-", "-post")= ""
+ * StringUtils.extendIfNotEmpty(" ", "pre-", "-post")   = "pre- -post"
+ * StringUtils.extendIfNotEmpty("bat", "pre-", "-post") = 
"pre-bat-bost"
+ * StringUtils.extendIfNotEmpty("bat", null, "-post")  = "bat-post"
+ * StringUtils.extendIfNotEmpty("bat", "pre-", null)  = "pre-bat"
+ * 
+ * @param str the String to check, may be null
+ * @param prefix  the string to prepend if not empty. Null will be 
converted to empty string.
+ * @param suffix  the string to append if not empty. Null will be 
converted to empty string.
+ * @return the passed in String with prefix and suffix added, or empty 
string
+ * @see StringUtils#defaultString(String, String)
+ */
+public static String extendIfNotEmpty(final String str, final String 
prefix, final String suffix) {
+return isEmpty(str) ? "" : defaultString(prefix) + str + 
defaultString(suffix);
--- End diff --

Reuse the EMPTY constant.


---

[jira] [Commented] (LANG-1352) EnumUtils.getEnumIgnoreCase and isValidEnumIgnoreCase methods added

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324242#comment-16324242
 ] 

ASF GitHub Bot commented on LANG-1352:
--

Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/286


> EnumUtils.getEnumIgnoreCase and isValidEnumIgnoreCase methods added
> ---
>
> Key: LANG-1352
> URL: https://issues.apache.org/jira/browse/LANG-1352
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Reporter: Ruslan Sibgatullin
>Priority: Minor
> Fix For: 3.8
>
>
> EnumUtils.getEnumIgnoreCase and isValidEnumIgnoreCase methods added.
> I truly believe that such handy method must exist in this utility class.
> [This|https://stackoverflow.com/questions/28332924/case-insensitive-matching-of-a-string-to-a-java-enum]
>  SO thread is just a prove of it. And also in the project I work for we need 
> to perform this operation quite often. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LANG-1352) EnumUtils.getEnumIgnoreCase and isValidEnumIgnoreCase methods added

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved LANG-1352.
-
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 3.8

> EnumUtils.getEnumIgnoreCase and isValidEnumIgnoreCase methods added
> ---
>
> Key: LANG-1352
> URL: https://issues.apache.org/jira/browse/LANG-1352
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Reporter: Ruslan Sibgatullin
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 3.8
>
>
> EnumUtils.getEnumIgnoreCase and isValidEnumIgnoreCase methods added.
> I truly believe that such handy method must exist in this utility class.
> [This|https://stackoverflow.com/questions/28332924/case-insensitive-matching-of-a-string-to-a-java-enum]
>  SO thread is just a prove of it. And also in the project I work for we need 
> to perform this operation quite often. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LANG-1352) EnumUtils.getEnumIgnoreCase and isValidEnumIgnoreCase methods added

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324240#comment-16324240
 ] 

ASF GitHub Bot commented on LANG-1352:
--

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/286
  
Thanks!  


> EnumUtils.getEnumIgnoreCase and isValidEnumIgnoreCase methods added
> ---
>
> Key: LANG-1352
> URL: https://issues.apache.org/jira/browse/LANG-1352
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Reporter: Ruslan Sibgatullin
>Priority: Minor
> Fix For: 3.8
>
>
> EnumUtils.getEnumIgnoreCase and isValidEnumIgnoreCase methods added.
> I truly believe that such handy method must exist in this utility class.
> [This|https://stackoverflow.com/questions/28332924/case-insensitive-matching-of-a-string-to-a-java-enum]
>  SO thread is just a prove of it. And also in the project I work for we need 
> to perform this operation quite often. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang pull request #286: LANG-1352 EnumUtils.getEnumIgnoreCase and is...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/286


---

[GitHub] commons-lang issue #286: LANG-1352 EnumUtils.getEnumIgnoreCase and isValidEn...

[PascalSchumacher]

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/286
  
Thanks! 👍 


---

[jira] [Closed] (JEXL-247) Possible value loss in case of coersion of BigInteger to BigDecimal

[Dmitri Blinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JEXL-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitri Blinov closed JEXL-247.
--
Resolution: Not A Problem

Sorry, the code transforms BigInteger using toString(), so the problem should 
not happen.

> Possible value loss in case of coersion of BigInteger to BigDecimal
> ---
>
> Key: JEXL-247
> URL: https://issues.apache.org/jira/browse/JEXL-247
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>
> It seems that {{JexlArithmetic.toBigDecimal}} method does not have a special 
> treatment for {{BigInteger}} type, only for {{Number}}, which can lead to 
> value loss in arithmetic operations for values greater than 
> {{Long.MAX_VALUE}} 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JEXL-247) Possible value loss in case of coersion of BigInteger to BigDecimal

[Dmitri Blinov (JIRA)]

Dmitri Blinov created JEXL-247:
--

 Summary: Possible value loss in case of coersion of BigInteger to 
BigDecimal
 Key: JEXL-247
 URL: https://issues.apache.org/jira/browse/JEXL-247
 Project: Commons JEXL
  Issue Type: Bug
Affects Versions: 3.1
Reporter: Dmitri Blinov


It seems that {{JexlArithmetic.toBigDecimal}} method does not have a special 
treatment for {{BigInteger}} type, only for {{Number}}, which can lead to value 
loss in arithmetic operations for values greater than {{Long.MAX_VALUE}} 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-439) Compressing and decompressing using Pack200 does not produce the original input

[Stefan Bodewig (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324193#comment-16324193
 ] 

Stefan Bodewig commented on COMPRESS-439:
-

no need to apologize. It is not obvious if you don't really know pack200.

> Compressing and decompressing using Pack200 does not produce the original 
> input
> ---
>
> Key: COMPRESS-439
> URL: https://issues.apache.org/jira/browse/COMPRESS-439
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Compressors
>Affects Versions: 1.14, 1.15
> Environment: Windows 7;
> # java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Valentin Brandl
>Priority: Minor
> Attachments: Test.java
>
>
> tI just tested different compressors using 
> [JUnitQuickcheck|https://github.com/pholser/junit-quickcheck].
> The tests should compress and then decompress some input and the result 
> should be equal to the input.
> For gzip, bzip2, deflate and xz, this works as intended but pack200 seems to 
> have some problems.
> I will attach the testcase I wrote.
> It seems that for empty input, the result won't be empty.
> Test output:
> ```
> input.length = 0
> input = []
> compressed.length = 19
> compressed = [-54, -2, -48, 13, 7, -106, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 3, 45, 
> 0]
> decompressed.length = 29
> decompressed = [80, 75, 5, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
> 7, 0, 80, 65, 67, 75, 50, 48, 48]
> ```



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (COMPRESS-440) Speed up decoder for deflate64

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig resolved COMPRESS-440.
-
   Resolution: Fixed
Fix Version/s: 1.16

Thanks!

> Speed up decoder for deflate64
> --
>
> Key: COMPRESS-440
> URL: https://issues.apache.org/jira/browse/COMPRESS-440
> Project: Commons Compress
>  Issue Type: Improvement
>Reporter: Dawid Weiss
>Priority: Minor
> Fix For: 1.16
>
>
> With the buffer applied in COMPRESS-438 the decompression speed is actually 
> quite all right, but there's still room for improvement. I was quite curious 
> what the bounds for pure-java inflater would be and hacked a quick experiment 
> with ZipFile using jzlib's implementation [1] to decompress a large-ish 
> archive (openjdk8 repository).
> The results for deflate, deflate64 and java's built-in decompressor are below.
> {code}
> Java (Inflater):
> archive.zip 4.38 sec., 444,357,134 archived => 731,621,181 decompressed
> jzlib's pure-java inflater:
> archive.zip 6.65 sec., 444,357,134 archived => 731,621,181 decompressed
> current deflate64 in commons-compress (with my allocation-reducing patch):
> archive64.zip 11.35 sec., 443,209,798 archived => 731,630,120 decompressed
> {code}
> [1] http://www.jcraft.com/jzlib/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (JEXL-246) Intermittent ambiguous method invocation when processing assignOverload

[Dmitri Blinov (JIRA)]

[ 
https://issues.apache.org/jira/browse/JEXL-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324122#comment-16324122
 ] 

Dmitri Blinov edited comment on JEXL-246 at 1/12/18 3:40 PM:
-

As it has turned out for me, Jexl restricts me, for some reason, from 
overloading operators in Arithmetic, if the operator signature is of 
generalized form, like {{operator(Object)}} or {{operator(Object, Object)}}. So 
the idea of having {{public JexlOperator selfAdd(Object x, Object y)}} does not 
apply. I don't know if it worth raising an issue about that, or it's better to 
find the more appropriate solution to the original problem. Lets not 
over-complicate. Suppose, we have an original script for {{z += 1}} and 
standard Arithmetic without any {{selfAdd}} overloaded operators. Should this 
work for an empty z value? I think it should. So, it should work exactly the 
same as with any number of {{selfAdd}} overloaded operators too. It's not an 
ambiguity, it's like Jexl couldn't find an appropriate overloaded operator for 
this case, and reverted to the default implementation.


was (Author: dmitri_blinov):
As it has turned out for me, Jexl restricts me, for some reason, from 
overloading operators in Arithmetic, if the operator signature is of 
generalized form, like {{operator(Object)}} or {{operator(Object, Object)}}. So 
the idea of having {{public JexlOperator selfAdd(Object x, Object y)}} does not 
apply. I don't know if it worth raising an issue about that, or it's better to 
find more appropriate the solution to the original problem. Lets not 
over-complicate. Suppose, we have an original script for {{z += 1}} and 
standard Arithmetic without any {{selfAdd}} overloaded operators. Should this 
work for an empty z value? I think it should. So, it should work exactly the 
same as with any number of {{selfAdd}} overloaded operators too. It's not an 
ambiguity, it's like Jexl couldn't find an appropriate overloaded operator for 
this case, and reverted to the default implementation.

> Intermittent ambiguous method invocation when processing assignOverload
> ---
>
> Key: JEXL-246
> URL: https://issues.apache.org/jira/browse/JEXL-246
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> Sometimes the simple operator like {code}z += 1{code} when {{z}} has not been 
> defined yet raises an exception 
> {{org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException}}
>  with the following stack trace: 
> {quote}
> ambiguous method invocation: MyArithmetic.selfAdd(null, java.lang.Integer)
> org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException: 
> null
>   at 
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.getMostSpecific(MethodKey.java:540)
>   at 
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.access$000(MethodKey.java:452)
>   at 
> org.apache.commons.jexl3.internal.introspection.MethodKey.getMostSpecificMethod(MethodKey.java:261)
>   at 
> org.apache.commons.jexl3.internal.introspection.ClassMap.getMethod(ClassMap.java:178)
>  
>   at 
> org.apache.commons.jexl3.internal.introspection.Introspector.getMethod(Introspector.java:146)
>   at 
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.discover(MethodExecutor.java:52)
>   at 
> org.apache.commons.jexl3.internal.introspection.Uberspect.getMethod(Uberspect.java:218)
>  
>   at MyUberspect.getMethod(MyUberspect.java:168)
>   at 
> org.apache.commons.jexl3.internal.introspection.Uberspect$ArithmeticUberspect.getOperator(Uberspect.java:413)
>   at 
> org.apache.commons.jexl3.internal.Operators.tryOverload(Operators.java:85) 
>   at 
> org.apache.commons.jexl3.internal.Operators.tryAssignOverload(Operators.java:118)
>  
>   at 
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1292)
>  
>   at 
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1102) 
> 
> {quote}
> The class MyArithmetic contains a couple of overloaded
> {{public JexlOperator selfAdd(T x, Object y)}} methods with the first 
> argument being the desired type {{T}} like {{Appendable}} or {{Collection}} 
> for which the {{+=}} operator is overloaded.
> Obviously in case where the first argument is null and the second argument is 
> an Integer it is not possible to differentiate between {{public JexlOperator 
> selfAdd(Collection x, Object y)}} and {{public JexlOperator 
> selfAdd(Appendable x, Object y)}} but I wonder is there any point in trying 
> to perform {{selfAdd}} on the null variable? What questions me more is that 
> this error is 

[jira] [Commented] (JEXL-246) Intermittent ambiguous method invocation when processing assignOverload

[Dmitri Blinov (JIRA)]

[ 
https://issues.apache.org/jira/browse/JEXL-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324122#comment-16324122
 ] 

Dmitri Blinov commented on JEXL-246:


As it has turned out for me, Jexl restricts me, for some reason, from 
overloading operators in Arithmetic, if the operator signature is of 
generalized form, like {{operator(Object)}} or {{operator(Object, Object)}}. So 
the idea of having {{public JexlOperator selfAdd(Object x, Object y)}} does not 
apply. I don't know if it worth raising an issue about that, or it's better to 
find more appropriate the solution to the original problem. Lets not 
over-complicate. Suppose, we have an original script for {{z += 1}} and 
standard Arithmetic without any {{selfAdd}} overloaded operators. Should this 
work for an empty z value? I think it should. So, it should work exactly the 
same as with any number of {{selfAdd}} overloaded operators too. It's not an 
ambiguity, it's like Jexl couldn't find an appropriate overloaded operator for 
this case, and reverted to the default implementation.

> Intermittent ambiguous method invocation when processing assignOverload
> ---
>
> Key: JEXL-246
> URL: https://issues.apache.org/jira/browse/JEXL-246
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> Sometimes the simple operator like {code}z += 1{code} when {{z}} has not been 
> defined yet raises an exception 
> {{org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException}}
>  with the following stack trace: 
> {quote}
> ambiguous method invocation: MyArithmetic.selfAdd(null, java.lang.Integer)
> org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException: 
> null
>   at 
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.getMostSpecific(MethodKey.java:540)
>   at 
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.access$000(MethodKey.java:452)
>   at 
> org.apache.commons.jexl3.internal.introspection.MethodKey.getMostSpecificMethod(MethodKey.java:261)
>   at 
> org.apache.commons.jexl3.internal.introspection.ClassMap.getMethod(ClassMap.java:178)
>  
>   at 
> org.apache.commons.jexl3.internal.introspection.Introspector.getMethod(Introspector.java:146)
>   at 
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.discover(MethodExecutor.java:52)
>   at 
> org.apache.commons.jexl3.internal.introspection.Uberspect.getMethod(Uberspect.java:218)
>  
>   at MyUberspect.getMethod(MyUberspect.java:168)
>   at 
> org.apache.commons.jexl3.internal.introspection.Uberspect$ArithmeticUberspect.getOperator(Uberspect.java:413)
>   at 
> org.apache.commons.jexl3.internal.Operators.tryOverload(Operators.java:85) 
>   at 
> org.apache.commons.jexl3.internal.Operators.tryAssignOverload(Operators.java:118)
>  
>   at 
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1292)
>  
>   at 
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1102) 
> 
> {quote}
> The class MyArithmetic contains a couple of overloaded
> {{public JexlOperator selfAdd(T x, Object y)}} methods with the first 
> argument being the desired type {{T}} like {{Appendable}} or {{Collection}} 
> for which the {{+=}} operator is overloaded.
> Obviously in case where the first argument is null and the second argument is 
> an Integer it is not possible to differentiate between {{public JexlOperator 
> selfAdd(Collection x, Object y)}} and {{public JexlOperator 
> selfAdd(Appendable x, Object y)}} but I wonder is there any point in trying 
> to perform {{selfAdd}} on the null variable? What questions me more is that 
> this error is intermittent and sometimes there is an exception and sometimes 
> there is not, so at the moment I have no test case to reproduce. So I think 
> this is a bug.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (RNG-42) Use Ziggurat implementation in other samplers

[Gilles (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RNG-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles resolved RNG-42.
---
Resolution: Fixed

commit d1105853ea4bdb5a330b6b697a96900c77f50dff

> Use Ziggurat implementation in other samplers
> -
>
> Key: RNG-42
> URL: https://issues.apache.org/jira/browse/RNG-42
> Project: Commons RNG
>  Issue Type: Improvement
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Fix For: 1.1
>
>
> Some samplers use an underlying {{NormalizedGaussianSampler}}.
> They should be upgraded to use {{ZigguratNormalizedGaussianSampler}} since it 
> is faster.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (COMPRESS-441) Remove dummyByte workaround from BoundedInputStream and use SequentialInputStream instead

[Dawid Weiss (JIRA)]

Dawid Weiss created COMPRESS-441:


 Summary: Remove dummyByte workaround from BoundedInputStream and 
use SequentialInputStream instead
 Key: COMPRESS-441
 URL: https://issues.apache.org/jira/browse/COMPRESS-441
 Project: Commons Compress
  Issue Type: Improvement
Reporter: Dawid Weiss
Priority: Trivial






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MATH-1367) DBSCAN Implementation does not count the seed point itself as part of its neighbors count

[jiaopaner (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16323717#comment-16323717
 ] 

jiaopaner commented on MATH-1367:
-

Hello,Amol
I quite agree with your opinion .I also found this problem when I use the 
DBSCAN algorithm.The version I used is apache-commons -math-3.6.1.
So the problem still exists,and I also found other problems in addition to the 
above problem.The time complexity of the algorithm is always n^2 when I 
test.Besides that,there are many no necessary operations in the algorithm 
implementation.BTW,why only DoublePoint, no StringPoint, so I can't use 
Levenshtein distance to search the adjacency points.I'll create a detailed bug 
report .

> DBSCAN Implementation does not count the seed point itself as part of its 
> neighbors count
> -
>
> Key: MATH-1367
> URL: https://issues.apache.org/jira/browse/MATH-1367
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Amol Singh
> Fix For: 4.0
>
>
> The DSCAN paper describes the eps-neighborhood of a point as 
> https://www.aaai.org/Papers/KDD/1996/KDD96-037.pdf (Page 2)
> Definition 1: (Eps-neighborhood of a point) The Eps-neighborhood of a point 
> p, denoted by NEps(p), is defined by NEps(p) = {q ∈ D | dist(p,q)< Eps} 
> in other words for all q points that are a member of database D whose 
> distance from p is less that Eps should be classified as a neighbor. This 
> should include the point itself. 
> The implementation however has a reference check to the point itself and does 
> not add it to its neighbors list.
> private List getNeighbors(final T point, final Collection points) {
> final List neighbors = new ArrayList();
> for (final T neighbor : points) {
> if (point != neighbor && distance(neighbor, point) <= eps) {
> neighbors.add(neighbor);
> }
> }
> return neighbors;
> } 
> "point != neighbor "  check should be removed here. Keeping this check 
> effectively is raising the minPts count by 1. Other third party QuadTree 
> backed DBSCAN implementations consider the center point in its neighbor count 
> E.g. bmw-carit library. 
> If this is infact by design, the check should use value equality instead of 
> reference equality. T extends Clusterable , the client should be able to 
> define this behavior. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (COMPRESS-439) Compressing and decompressing using Pack200 does not produce the original input

[Valentin Brandl (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Valentin Brandl updated COMPRESS-439:
-
Description: 
tI just tested different compressors using 
[JUnitQuickcheck|https://github.com/pholser/junit-quickcheck].
The tests should compress and then decompress some input and the result should 
be equal to the input.
For gzip, bzip2, deflate and xz, this works as intended but pack200 seems to 
have some problems.
I will attach the testcase I wrote.
It seems that for empty input, the result won't be empty.

Test output:
```
input.length = 0
input = []
compressed.length = 19
compressed = [-54, -2, -48, 13, 7, -106, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 3, 45, 0]
decompressed.length = 29
decompressed = [80, 75, 5, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
7, 0, 80, 65, 67, 75, 50, 48, 48]
```

  was:
I just tested different compressors using 
[JUnitQuickcheck|https://github.com/pholser/junit-quickcheck].
The tests should compress and then decompress some input and the result should 
be equal to the input.
For gzip, bzip2, deflate and xz, this works as intended but pack200 seems to 
have some problems.
I will attach the testcase I wrote.
It seems that for empty input, the result won't be empty.

Test output:
```
input.length = 0
input = []
compressed.length = 19
compressed = [-54, -2, -48, 13, 7, -106, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 3, 45, 0]
decompressed.length = 29
decompressed = [80, 75, 5, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
7, 0, 80, 65, 67, 75, 50, 48, 48]
```


> Compressing and decompressing using Pack200 does not produce the original 
> input
> ---
>
> Key: COMPRESS-439
> URL: https://issues.apache.org/jira/browse/COMPRESS-439
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Compressors
>Affects Versions: 1.14, 1.15
> Environment: Windows 7;
> # java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Valentin Brandl
>Priority: Minor
> Attachments: Test.java
>
>
> tI just tested different compressors using 
> [JUnitQuickcheck|https://github.com/pholser/junit-quickcheck].
> The tests should compress and then decompress some input and the result 
> should be equal to the input.
> For gzip, bzip2, deflate and xz, this works as intended but pack200 seems to 
> have some problems.
> I will attach the testcase I wrote.
> It seems that for empty input, the result won't be empty.
> Test output:
> ```
> input.length = 0
> input = []
> compressed.length = 19
> compressed = [-54, -2, -48, 13, 7, -106, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 3, 45, 
> 0]
> decompressed.length = 29
> decompressed = [80, 75, 5, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
> 7, 0, 80, 65, 67, 75, 50, 48, 48]
> ```



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)