[jira] [Commented] (RNG-37) Ziggurat algorithm

2017-10-09 Thread Bruno P. Kinoshita (JIRA)

[ 
https://issues.apache.org/jira/browse/RNG-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198178#comment-16198178
 ] 

Bruno P. Kinoshita commented on RNG-37:
---

>I've checked, all samplers in 
>commons-rng-sampling/src/main/java/org/apache/commons/rng/sampling/distribution
> except one have this format. So, I assume it's how it's expected, I've left 
>it as is.

You are correct, checked another class. Thanks for looking into that Olga.

Commented your pull request :-) we are making good progress. Thank **you** for 
your contribution and patience.

Cheers
Bruno

> Ziggurat algorithm
> --
>
> Key: RNG-37
> URL: https://issues.apache.org/jira/browse/RNG-37
> Project: Commons RNG
>  Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
>
> Fast algorithm for sampling a Gaussian distribution: 
> https://en.wikipedia.org/wiki/Ziggurat_algorithm



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


[jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

2017-10-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on LANG-1355:
--

Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://coveralls.io/builds/13642621/badge)](https://coveralls.io/builds/13642621)

Coverage decreased (-0.01%) to 95.192% when pulling 
**0476df2d4276da567e5f6bbf64813e9fff0fa7d5 on chonton:LANG-1355** into 
**15d5503215a4cd1efc1ae6659d82194a22ebee9b on apache:master**.



> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



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


[GitHub] commons-lang issue #296: LANG-1355: Add FastTimeZone to decrease TimeZone.ge...

2017-10-09 Thread coveralls
Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://coveralls.io/builds/13642621/badge)](https://coveralls.io/builds/13642621)

Coverage decreased (-0.01%) to 95.192% when pulling 
**0476df2d4276da567e5f6bbf64813e9fff0fa7d5 on chonton:LANG-1355** into 
**15d5503215a4cd1efc1ae6659d82194a22ebee9b on apache:master**.



---


[jira] [Updated] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

2017-10-09 Thread Charles Honton (JIRA)

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

Charles Honton updated LANG-1355:
-
Assignee: Charles Honton

> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



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


[jira] [Commented] (TEXT-74) StrSubstitutor: Ability to turn off substitution in values

2017-10-09 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TEXT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197859#comment-16197859
 ] 

ASF GitHub Bot commented on TEXT-74:


Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/68
  

[![Coverage 
Status](https://coveralls.io/builds/13640479/badge)](https://coveralls.io/builds/13640479)

Coverage increased (+0.003%) to 98.239% when pulling 
**635cb80d1cb0d32fddfe86be75b0a30eb3d3fab7 on sermojohn:TEXT-74** into 
**317ae8452bb616d4dcbdd9b9d561d8daf2bb5260 on apache:master**.



> StrSubstitutor: Ability to turn off substitution in values
> --
>
> Key: TEXT-74
> URL: https://issues.apache.org/jira/browse/TEXT-74
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Arend v. Reinersdorff
>Priority: Minor
>  Labels: features
> Fix For: 1.x
>
>
> StrSubstitutor replaces variables in values. 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 replacement 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:
> {code}
> Hello Hamburg from Hamburg
> {code}
> The commented line is my suggestion for this feature. If it works, it should 
> print:
> {code}
> Hello ${city} from Hamburg
> {code}
> {code}
> // untrusted user input
> String userInputName = "${city}";
> String userInputCity = "Hamburg";
> Map valueMap = new HashMap<>();
> valueMap.put("name", userInputName);
> valueMap.put("city", userInputCity);
> String source = "Hello ${name} from ${city}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));
> {code}



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


[jira] [Commented] (TEXT-74) StrSubstitutor: Ability to turn off substitution in values

2017-10-09 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TEXT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197858#comment-16197858
 ] 

ASF GitHub Bot commented on TEXT-74:


Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/68
  

[![Coverage 
Status](https://coveralls.io/builds/13640479/badge)](https://coveralls.io/builds/13640479)

Coverage increased (+0.003%) to 98.239% when pulling 
**635cb80d1cb0d32fddfe86be75b0a30eb3d3fab7 on sermojohn:TEXT-74** into 
**317ae8452bb616d4dcbdd9b9d561d8daf2bb5260 on apache:master**.



> StrSubstitutor: Ability to turn off substitution in values
> --
>
> Key: TEXT-74
> URL: https://issues.apache.org/jira/browse/TEXT-74
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Arend v. Reinersdorff
>Priority: Minor
>  Labels: features
> Fix For: 1.x
>
>
> StrSubstitutor replaces variables in values. 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 replacement 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:
> {code}
> Hello Hamburg from Hamburg
> {code}
> The commented line is my suggestion for this feature. If it works, it should 
> print:
> {code}
> Hello ${city} from Hamburg
> {code}
> {code}
> // untrusted user input
> String userInputName = "${city}";
> String userInputCity = "Hamburg";
> Map valueMap = new HashMap<>();
> valueMap.put("name", userInputName);
> valueMap.put("city", userInputCity);
> String source = "Hello ${name} from ${city}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));
> {code}



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


[GitHub] commons-lang pull request #:

2017-10-09 Thread garydgregory
Github user garydgregory commented on the pull request:


https://github.com/apache/commons-lang/commit/d848328a7aa54f73117b8f13ce6e67049dc9502e#commitcomment-24866944
  
"3.6 already requires java 7." I think it is nice to state the plaform 
requirement for any component. Often time, one is left guessing or hunting down 
POMs for compiler settings.


---


[GitHub] commons-lang pull request #:

2017-10-09 Thread PascalSchumacher
Github user PascalSchumacher commented on the pull request:


https://github.com/apache/commons-lang/commit/d848328a7aa54f73117b8f13ce6e67049dc9502e#commitcomment-24866834
  
`3.6` already requires java 7.

Also the builds on travis fail with:

```There are 8 errors reported by Checkstyle 6.11.2 with 
/home/travis/build/apache/commons-lang/checkstyle.xml ruleset.
[ERROR] 
src/main/java/org/apache/commons/lang3/time/FastDateParser.java:[959] (regexp) 
RegexpSingleline: Line has trailing spaces.
[ERROR] 
src/main/java/org/apache/commons/lang3/time/FastDateParser.java:[971] (regexp) 
RegexpSingleline: Line has trailing spaces.
[ERROR] 
src/main/java/org/apache/commons/lang3/time/FastDateParser.java:[980] (regexp) 
RegexpSingleline: Line has trailing spaces.
[ERROR] 
src/main/java/org/apache/commons/lang3/time/FastDateParser.java:[987] (regexp) 
RegexpSingleline: Line has trailing spaces.
[ERROR] 
src/test/java/org/apache/commons/lang3/text/ExtendedMessageFormatTest.java:[427]
 (regexp) RegexpSingleline: Line has trailing spaces.
[ERROR] 
src/test/java/org/apache/commons/lang3/text/ExtendedMessageFormatTest.java:[441]
 (regexp) RegexpSingleline: Line has trailing spaces.
[ERROR] 
src/test/java/org/apache/commons/lang3/text/ExtendedMessageFormatTest.java:[452]
 (regexp) RegexpSingleline: Line has trailing spaces.
[ERROR] 
src/test/java/org/apache/commons/lang3/text/ExtendedMessageFormatTest.java:[462]
 (regexp) RegexpSingleline: Line has trailing spaces.```


---


[GitHub] commons-lang issue #297: Add a rule of Locale.ENGLISH to String.toUpperCase(...

2017-10-09 Thread garydgregory
Github user garydgregory commented on the issue:

https://github.com/apache/commons-lang/pull/297
  
I fixed some tests and code main code here and there and I think all the 
changes we need are in. If you feel otherwise, please update this PR based on 
git master. Thank you!


---


[jira] [Commented] (VFS-524) The uri include ipv6 address can't be parsed out correctly

2017-10-09 Thread Gary Gregory (JIRA)

[ 
https://issues.apache.org/jira/browse/VFS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197676#comment-16197676
 ] 

Gary Gregory commented on VFS-524:
--

I just need a fresh PR ;-)

> The uri include ipv6 address can't be parsed out correctly
> --
>
> Key: VFS-524
> URL: https://issues.apache.org/jira/browse/VFS-524
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Alex
> Attachments: VFS-524-v2.patch, VFS-524-v3.patch
>
>
> I am using apache commons vfs2 to read and download file in ipv6 enviroment, 
> but it seems can't parse out ipv6 address correctly
> The URI is just like:
> ftp://[2002:9ba:b4e:6:a052:5792:c0c9:2330]/test
> The error message:
> Invalid absolute URI "ftp://[2002:9ba:b4e:6:a052:5792:c0c9:2330]/test;.
> Caused by : Expecting / to follow the hostname in URI 
> "ftp://[2002:9ba:b4e:6:a052:5792:c0c9:2330]/test;.
> Deep into the code, I found the root cause is that HostFileNameParser's 
> extractHostName can't parse out the host name correctly
> {noformat}
> /**
>  * Extracts the hostname from a URI.  The scheme://userinfo@ part has
>  * been removed.
>  */
> protected String extractHostName(final StringBuilder name)
> {
> final int maxlen = name.length();
> int pos = 0;
> for (; pos < maxlen; pos++)
> {
> final char ch = name.charAt(pos);
> if (ch == '/' || ch == ';' || ch == '?' || ch == ':'
> || ch == '@' || ch == '&' || ch == '=' || ch == '+'
> || ch == '$' || ch == ',')
> {
> break;
> }
> }
> if (pos == 0)
> {
> return null;
> }
> final String hostname = name.substring(0, pos);
> name.delete(0, pos);
> return hostname;
> }
> {noformat}
> From the code, we are able to know it will  parse out the host name by colon, 
> but for ipv6, it will get a wrong host name
> There is the same problem with the other protocol like sftp and cifs



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


[jira] [Closed] (CSV-217) Add autoFlush option for CSVPrinter

2017-10-09 Thread Korolyov Alexei (JIRA)

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

Korolyov Alexei closed CSV-217.
---

Thank you!

> Add autoFlush option for CSVPrinter
> ---
>
> Key: CSV-217
> URL: https://issues.apache.org/jira/browse/CSV-217
> Project: Commons CSV
>  Issue Type: Bug
>  Components: Printer
>Reporter: Korolyov Alexei
>Priority: Minor
> Fix For: 1.6
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> CsvPrinter doesn't flush data on close. Looks like a bug, for me.
> Updated: Add an option "autoFlush" to CSVFormat to be used by CSVPrinter.



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


[jira] [Closed] (LANG-1357) org.apache.commons.lang3.time.FastDateParser should use toUpperCase(Locale)

2017-10-09 Thread Gary Gregory (JIRA)

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

Gary Gregory closed LANG-1357.
--
   Resolution: Fixed
Fix Version/s: 3.7

Closing: In git master.

> org.apache.commons.lang3.time.FastDateParser should use toUpperCase(Locale)
> ---
>
> Key: LANG-1357
> URL: https://issues.apache.org/jira/browse/LANG-1357
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 3.7
>
>
> The class org.apache.commons.lang3.time.FastDateParser should use 
> {{toUpperCase(Locale)}} internally to avoid i18n issues 
> https://garygregory.wordpress.com/2015/11/03/java-lowercase-conversion-turkey/



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


[jira] [Commented] (VFS-524) The uri include ipv6 address can't be parsed out correctly

2017-10-09 Thread David So (JIRA)

[ 
https://issues.apache.org/jira/browse/VFS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197650#comment-16197650
 ] 

David So commented on VFS-524:
--

(y) That will be great.

> The uri include ipv6 address can't be parsed out correctly
> --
>
> Key: VFS-524
> URL: https://issues.apache.org/jira/browse/VFS-524
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Alex
> Attachments: VFS-524-v2.patch, VFS-524-v3.patch
>
>
> I am using apache commons vfs2 to read and download file in ipv6 enviroment, 
> but it seems can't parse out ipv6 address correctly
> The URI is just like:
> ftp://[2002:9ba:b4e:6:a052:5792:c0c9:2330]/test
> The error message:
> Invalid absolute URI "ftp://[2002:9ba:b4e:6:a052:5792:c0c9:2330]/test;.
> Caused by : Expecting / to follow the hostname in URI 
> "ftp://[2002:9ba:b4e:6:a052:5792:c0c9:2330]/test;.
> Deep into the code, I found the root cause is that HostFileNameParser's 
> extractHostName can't parse out the host name correctly
> {noformat}
> /**
>  * Extracts the hostname from a URI.  The scheme://userinfo@ part has
>  * been removed.
>  */
> protected String extractHostName(final StringBuilder name)
> {
> final int maxlen = name.length();
> int pos = 0;
> for (; pos < maxlen; pos++)
> {
> final char ch = name.charAt(pos);
> if (ch == '/' || ch == ';' || ch == '?' || ch == ':'
> || ch == '@' || ch == '&' || ch == '=' || ch == '+'
> || ch == '$' || ch == ',')
> {
> break;
> }
> }
> if (pos == 0)
> {
> return null;
> }
> final String hostname = name.substring(0, pos);
> name.delete(0, pos);
> return hostname;
> }
> {noformat}
> From the code, we are able to know it will  parse out the host name by colon, 
> but for ipv6, it will get a wrong host name
> There is the same problem with the other protocol like sftp and cifs



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


[jira] [Updated] (LANG-1357) org.apache.commons.lang3.time.FastDateParser should use toUpperCase(Locale)

2017-10-09 Thread Gary Gregory (JIRA)

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

Gary Gregory updated LANG-1357:
---
Description: The class org.apache.commons.lang3.time.FastDateParser should 
use {{toUpperCase(Locale)}} internally to avoid i18n issues 
https://garygregory.wordpress.com/2015/11/03/java-lowercase-conversion-turkey/  
(was: The class org.apache.commons.lang3.time.FastDateParser should use 
toUpperCase(Locale) to avoid i18n issues 
https://garygregory.wordpress.com/2015/11/03/java-lowercase-conversion-turkey/)

> org.apache.commons.lang3.time.FastDateParser should use toUpperCase(Locale)
> ---
>
> Key: LANG-1357
> URL: https://issues.apache.org/jira/browse/LANG-1357
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> The class org.apache.commons.lang3.time.FastDateParser should use 
> {{toUpperCase(Locale)}} internally to avoid i18n issues 
> https://garygregory.wordpress.com/2015/11/03/java-lowercase-conversion-turkey/



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


[jira] [Commented] (LANG-1357) org.apache.commons.lang3.time.FastDateParser should use toUpperCase(Locale)

2017-10-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on LANG-1357:
--

Github user garydgregory commented on the issue:

https://github.com/apache/commons-lang/pull/297
  
I am splitting out the FastDateParser changes here: 
https://issues.apache.org/jira/browse/LANG-1357


> org.apache.commons.lang3.time.FastDateParser should use toUpperCase(Locale)
> ---
>
> Key: LANG-1357
> URL: https://issues.apache.org/jira/browse/LANG-1357
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> The class org.apache.commons.lang3.time.FastDateParser should use 
> toUpperCase(Locale) to avoid i18n issues 
> https://garygregory.wordpress.com/2015/11/03/java-lowercase-conversion-turkey/



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


[GitHub] commons-lang issue #297: Add a rule of Locale.ENGLISH to String.toUpperCase(...

2017-10-09 Thread garydgregory
Github user garydgregory commented on the issue:

https://github.com/apache/commons-lang/pull/297
  
I am splitting out the FastDateParser changes here: 
https://issues.apache.org/jira/browse/LANG-1357


---


[jira] [Created] (LANG-1357) org.apache.commons.lang3.time.FastDateParser should use toUpperCase(Locale)

2017-10-09 Thread Gary Gregory (JIRA)
Gary Gregory created LANG-1357:
--

 Summary: org.apache.commons.lang3.time.FastDateParser should use 
toUpperCase(Locale)
 Key: LANG-1357
 URL: https://issues.apache.org/jira/browse/LANG-1357
 Project: Commons Lang
  Issue Type: Bug
  Components: lang.time.*
Affects Versions: 3.6
Reporter: Gary Gregory
Assignee: Gary Gregory


The class org.apache.commons.lang3.time.FastDateParser should use 
toUpperCase(Locale) to avoid i18n issues 
https://garygregory.wordpress.com/2015/11/03/java-lowercase-conversion-turkey/



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


[jira] [Resolved] (CSV-217) Add autoFlush option for CSVPrinter

2017-10-09 Thread Gary Gregory (JIRA)

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

Gary Gregory resolved CSV-217.
--
   Resolution: Fixed
Fix Version/s: 1.6

In git master. Please verify and close.

> Add autoFlush option for CSVPrinter
> ---
>
> Key: CSV-217
> URL: https://issues.apache.org/jira/browse/CSV-217
> Project: Commons CSV
>  Issue Type: Bug
>  Components: Printer
>Reporter: Korolyov Alexei
>Priority: Minor
> Fix For: 1.6
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> CsvPrinter doesn't flush data on close. Looks like a bug, for me.
> Updated: Add an option "autoFlush" to CSVFormat to be used by CSVPrinter.



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


[GitHub] commons-lang issue #297: Add a rule of Locale.ENGLISH to String.toUpperCase(...

2017-10-09 Thread coveralls
Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://coveralls.io/builds/13637420/badge)](https://coveralls.io/builds/13637420)

Coverage remained the same at 95.213% when pulling 
**989d02714efd99dad76380f88bbd7c430ccf92ec on BruceKuiLiu:master** into 
**00feb98f807cf44c993296052726043a90d70b7e on apache:master**.



---


[GitHub] commons-lang pull request #297: Add a rule of Locale.ENGLISH to String.toUpp...

2017-10-09 Thread PascalSchumacher
Github user PascalSchumacher commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/297#discussion_r143555903
  
--- Diff: src/main/java/org/apache/commons/lang3/time/FormatCache.java ---
@@ -240,7 +240,7 @@ public boolean equals(final Object obj) {
 // Eliminate the usual boilerplate because
 // this inner static class is only used in a generic 
ConcurrentHashMap
 // which will not compare against other Object types
-return Arrays.equals(keys, ((MultipartKey)obj).keys);
+return obj instanceof MultipartKey && Arrays.equals(keys, 
((MultipartKey)obj).keys);
--- End diff --

Please do not include unrelated changes in a single pull request. Thanks!


---


[jira] [Updated] (CSV-217) Add autoFlush option for CSVPrinter

2017-10-09 Thread Gary Gregory (JIRA)

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

Gary Gregory updated CSV-217:
-
Description: 
CsvPrinter doesn't flush data on close. Looks like a bug, for me.

Updated: Add an option "autoFlush" to CSVFormat to be used by CSVPrinter.

  was:CsvPrinter doesn't flush data on close. Looks like a bug, for me.


> Add autoFlush option for CSVPrinter
> ---
>
> Key: CSV-217
> URL: https://issues.apache.org/jira/browse/CSV-217
> Project: Commons CSV
>  Issue Type: Bug
>  Components: Printer
>Reporter: Korolyov Alexei
>Priority: Minor
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> CsvPrinter doesn't flush data on close. Looks like a bug, for me.
> Updated: Add an option "autoFlush" to CSVFormat to be used by CSVPrinter.



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


[jira] [Updated] (CSV-217) Add autoFlush option for CSVPrinter

2017-10-09 Thread Gary Gregory (JIRA)

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

Gary Gregory updated CSV-217:
-
Summary: Add autoFlush option for CSVPrinter  (was: Add autoFlush option 
for CsvPrinter)

> Add autoFlush option for CSVPrinter
> ---
>
> Key: CSV-217
> URL: https://issues.apache.org/jira/browse/CSV-217
> Project: Commons CSV
>  Issue Type: Bug
>  Components: Printer
>Reporter: Korolyov Alexei
>Priority: Minor
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> CsvPrinter doesn't flush data on close. Looks like a bug, for me.



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


[jira] [Updated] (CSV-217) Add autoFlush option for CsvPrinter

2017-10-09 Thread Gary Gregory (JIRA)

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

Gary Gregory updated CSV-217:
-
Summary: Add autoFlush option for CsvPrinter  (was: Add autoFlush option to 
CsvPrinter)

> Add autoFlush option for CsvPrinter
> ---
>
> Key: CSV-217
> URL: https://issues.apache.org/jira/browse/CSV-217
> Project: Commons CSV
>  Issue Type: Bug
>  Components: Printer
>Reporter: Korolyov Alexei
>Priority: Minor
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> CsvPrinter doesn't flush data on close. Looks like a bug, for me.



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


[jira] [Updated] (CSV-217) Add autoFlush option to CsvPrinter

2017-10-09 Thread Gary Gregory (JIRA)

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

Gary Gregory updated CSV-217:
-
Summary: Add autoFlush option to CsvPrinter  (was: CsvPrinter doesn't flush 
on close)

> Add autoFlush option to CsvPrinter
> --
>
> Key: CSV-217
> URL: https://issues.apache.org/jira/browse/CSV-217
> Project: Commons CSV
>  Issue Type: Bug
>  Components: Printer
>Reporter: Korolyov Alexei
>Priority: Minor
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> CsvPrinter doesn't flush data on close. Looks like a bug, for me.



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


[GitHub] commons-lang issue #298: Add an instanceof test in the implementation of equ...

2017-10-09 Thread BruceKuiLiu
Github user BruceKuiLiu commented on the issue:

https://github.com/apache/commons-lang/pull/298
  
I am sorry, I cannot provide any test cases.  We found it is a potential 
vulnerability.


---


[GitHub] commons-lang pull request #297: Add a rule of Locale.ENGLISH to String.toUpp...

2017-10-09 Thread BruceKuiLiu
GitHub user BruceKuiLiu reopened a pull request:

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

Add a rule of Locale.ENGLISH to String.toUpperCase() method.

A String is being converted to upper case, using the platform's default 
encoding.
This may result in improper conversions when used with international 
characters.
Use the String.toUpperCase( Locale l ) version should be better.
http://findbugs.sourceforge.net/bugDescriptions.html#DM_CONVERT_CASE

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/BruceKuiLiu/commons-lang master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/297.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #297


commit ac6ea81247282d7fd929195040acf333cebc7b80
Author: Kui LIU 
Date:   2017-10-09T14:01:42Z

Add a rule of Locale.ENGLISH to String.toUpperCase() method.

A String is being converted to upper case, using the platform's default 
encoding.
This may result in improper conversions when used with international 
characters.
Use the String.toUpperCase( Locale l ) version should be better.
http://findbugs.sourceforge.net/bugDescriptions.html#DM_CONVERT_CASE

commit 52696462449c37ed58457aa6e8a9b63a33863608
Author: Kui LIU 
Date:   2017-10-09T14:45:22Z

Add a rule of Locale.ENGLISH to String.toLowerCase() method.

A String is being converted to lower case, using the platform's default 
encoding.
This may result in improper conversions when used with international 
characters.
Use the String.toLowerCase( Locale l ) version should be better.
http://findbugs.sourceforge.net/bugDescriptions.html#DM_CONVERT_CASE

commit e5a77b7ac0195943ee9ab5a40e826102f5b7b19a
Author: Kui LIU 
Date:   2017-10-09T14:47:32Z

Add a rule of Locale.ENGLISH to String.toUpperCase() method.

A String is being converted to upper case, using the platform's default 
encoding.
This may result in improper conversions when used with international 
characters.
Use the String.toUpperCase( Locale l ) version should be better.
http://findbugs.sourceforge.net/bugDescriptions.html#DM_CONVERT_CASE

commit c3711c3d6d93fdc996bddc97e3dffa60f6c0119d
Author: Kui LIU 
Date:   2017-10-09T14:48:19Z

Add a rule of Locale.ENGLISH to String.toLowerCase() method.

A String is being converted to lower case, using the platform's default 
encoding.
This may result in improper conversions when used with international 
characters.
Use the String.toLowerCase( Locale l ) version should be better.
http://findbugs.sourceforge.net/bugDescriptions.html#DM_CONVERT_CASE

commit 0fc92622493b45d83c05574e16a4117ae54c7d72
Author: Kui LIU 
Date:   2017-10-09T14:49:45Z

Add a rule of Locale.ENGLISH to String.toLowerCase() method.

A String is being converted to lower case, using the platform's default 
encoding.
This may result in improper conversions when used with international 
characters.
Use the String.toLowerCase( Locale l ) version should be better.
http://findbugs.sourceforge.net/bugDescriptions.html#DM_CONVERT_CASE

commit 989d02714efd99dad76380f88bbd7c430ccf92ec
Author: Kui LIU 
Date:   2017-10-09T14:51:22Z

Add a rule of Locale.ENGLISH to String.toUpperCase() method.

A String is being converted to upper case, using the platform's default 
encoding.
This may result in improper conversions when used with international 
characters.
Use the String.toUpperCase( Locale l ) version should be better.
http://findbugs.sourceforge.net/bugDescriptions.html#DM_CONVERT_CASE

commit b08cfbb3847f58a10c6dcc15ee08da3b0e2b1d6a
Author: Kui LIU 
Date:   2017-10-09T18:04:34Z

Add an instanceof test in the implementation of equals(Object obj) method.

The equals(Object obj) method shouldn't make any assumptions about the type 
of obj. It should simply return false if obj is not the same type as this.

http://findbugs.sourceforge.net/bugDescriptions.html#BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS




---


[jira] [Commented] (RNG-37) Ziggurat algorithm

2017-10-09 Thread OlgaK (JIRA)

[ 
https://issues.apache.org/jira/browse/RNG-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197495#comment-16197495
 ] 

OlgaK commented on RNG-37:
--

thanks [~kinow] for your reply and comments. I've made a new [pull 
request|https://github.com/apache/commons-rng/pull/5] from the fork of 
commons-rng and implemented your suggestions in the last commit.
Regarding

+public class ZigguratGaussianSampler
+extends SamplerBase
Not sure which checkstyle rule will be used, but normally these are kept in a 
single line, unless it breaks the other rule of the maximum number of chars per 
line" 

I've checked, all samplers in 
commons-rng-sampling/src/main/java/org/apache/commons/rng/sampling/distribution 
except one have this format. So, I assume it's how it's expected, I've left it 
as is.   

> Ziggurat algorithm
> --
>
> Key: RNG-37
> URL: https://issues.apache.org/jira/browse/RNG-37
> Project: Commons RNG
>  Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
>
> Fast algorithm for sampling a Gaussian distribution: 
> https://en.wikipedia.org/wiki/Ziggurat_algorithm



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


[GitHub] commons-lang issue #298: Add an instanceof test in the implementation of equ...

2017-10-09 Thread PascalSchumacher
Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/298
  
The comment above the statement explains why it is done this way.

In case this is merged the comment should be removed.


---


[GitHub] commons-lang issue #298: Add an instanceof test in the implementation of equ...

2017-10-09 Thread kinow
Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/298
  
I think it makes sense. Any chance to include a unit test to protect 
against regressions in the future? Thanks


---


[GitHub] commons-lang issue #298: Add an instanceof test in the implementation of equ...

2017-10-09 Thread coveralls
Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://coveralls.io/builds/13636221/badge)](https://coveralls.io/builds/13636221)

Coverage remained the same at 95.213% when pulling 
**0ee26c5f74558628740b8347a9624efc65c86012 on BruceKuiLiu:trunk** into 
**00feb98f807cf44c993296052726043a90d70b7e on apache:master**.



---


[GitHub] commons-lang pull request #298: Add an instanceof test in the implementation...

2017-10-09 Thread BruceKuiLiu
GitHub user BruceKuiLiu opened a pull request:

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

Add an instanceof test in the implementation of equals(Object obj).

The equals(Object obj) method shouldn't make any assumptions about the type 
of obj. It should simply return false if obj is not the same type as this.

http://findbugs.sourceforge.net/bugDescriptions.html#BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/BruceKuiLiu/commons-lang trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/298.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #298


commit 0ee26c5f74558628740b8347a9624efc65c86012
Author: Kui LIU 
Date:   2017-10-09T18:17:23Z

Add an instanceof test in the implementation of equals(Object obj).

The equals(Object obj) method shouldn't make any assumptions about the type 
of obj. It should simply return false if obj is not the same type as this.

http://findbugs.sourceforge.net/bugDescriptions.html#BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS




---


[GitHub] commons-lang pull request #297: Add a rule of Locale.ENGLISH to String.toUpp...

2017-10-09 Thread BruceKuiLiu
Github user BruceKuiLiu closed the pull request at:

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


---


[GitHub] commons-lang issue #297: Add a rule of Locale.ENGLISH to String.toUpperCase(...

2017-10-09 Thread BruceKuiLiu
Github user BruceKuiLiu commented on the issue:

https://github.com/apache/commons-lang/pull/297
  
Right, Locale.ROOT should be the most appropriate.


---


[GitHub] commons-lang issue #297: Add a rule of Locale.ENGLISH to String.toUpperCase(...

2017-10-09 Thread garydgregory
Github user garydgregory commented on the issue:

https://github.com/apache/commons-lang/pull/297
  
Shouldn't this be done with Locale.ROOT?


---


[jira] [Commented] (DAEMON-376) Update Daemon to also search registry for JRE with Java 9 JRE location

2017-10-09 Thread Gary Gregory (JIRA)

[ 
https://issues.apache.org/jira/browse/DAEMON-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197250#comment-16197250
 ] 

Gary Gregory commented on DAEMON-376:
-

Patches welcome! :-)

> Update Daemon to also search registry for JRE with Java 9 JRE location
> --
>
> Key: DAEMON-376
> URL: https://issues.apache.org/jira/browse/DAEMON-376
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: Windows only
>Reporter: Mark Thomas
>
> Java 9:
> HKLM\SOFTWARE\JavaSoft\JRE
> Java 8 and earlier:
> HKLM\SOFTWARE\JavaSoft\Java Runtime Environment



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


[GitHub] commons-lang issue #297: Add a rule of Locale.ENGLISH to String.toUpperCase(...

2017-10-09 Thread BruceKuiLiu
Github user BruceKuiLiu commented on the issue:

https://github.com/apache/commons-lang/pull/297
  
Thanks. 


---


[GitHub] commons-lang issue #297: Add a rule of Locale.ENGLISH to String.toUpperCase(...

2017-10-09 Thread coveralls
Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://coveralls.io/builds/13633085/badge)](https://coveralls.io/builds/13633085)

Coverage remained the same at 95.213% when pulling 
**37223825a39a6cb57124d529bbe65e74a024b496 on BruceKuiLiu:master** into 
**00feb98f807cf44c993296052726043a90d70b7e on apache:master**.



---


[GitHub] commons-lang issue #297: Add a rule of Locale.ENGLISH to String.toUpperCase(...

2017-10-09 Thread coveralls
Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://coveralls.io/builds/13632762/badge)](https://coveralls.io/builds/13632762)

Coverage increased (+0.02%) to 95.233% when pulling 
**989d02714efd99dad76380f88bbd7c430ccf92ec on BruceKuiLiu:master** into 
**00feb98f807cf44c993296052726043a90d70b7e on apache:master**.



---


[GitHub] commons-lang issue #297: Add a rule of Locale.ENGLISH to String.toUpperCase(...

2017-10-09 Thread coveralls
Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://coveralls.io/builds/13632706/badge)](https://coveralls.io/builds/13632706)

Coverage remained the same at 95.213% when pulling 
**989d02714efd99dad76380f88bbd7c430ccf92ec on BruceKuiLiu:master** into 
**00feb98f807cf44c993296052726043a90d70b7e on apache:master**.



---


[GitHub] commons-lang issue #297: Add a rule of Locale.ENGLISH to String.toUpperCase(...

2017-10-09 Thread coveralls
Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://coveralls.io/builds/13632652/badge)](https://coveralls.io/builds/13632652)

Coverage remained the same at 95.213% when pulling 
**c3711c3d6d93fdc996bddc97e3dffa60f6c0119d on BruceKuiLiu:master** into 
**00feb98f807cf44c993296052726043a90d70b7e on apache:master**.



---


[GitHub] commons-lang issue #297: Add a rule of Locale.ENGLISH to String.toUpperCase(...

2017-10-09 Thread coveralls
Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://coveralls.io/builds/13632390/badge)](https://coveralls.io/builds/13632390)

Coverage remained the same at 95.213% when pulling 
**ac6ea81247282d7fd929195040acf333cebc7b80 on BruceKuiLiu:master** into 
**00feb98f807cf44c993296052726043a90d70b7e on apache:master**.



---


[GitHub] commons-lang pull request #297: Add a rule of Locale.ENGLISH to String.toUpp...

2017-10-09 Thread BruceKuiLiu
GitHub user BruceKuiLiu opened a pull request:

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

Add a rule of Locale.ENGLISH to String.toUpperCase() method.

A String is being converted to upper case, using the platform's default 
encoding.
This may result in improper conversions when used with international 
characters.
Use the String.toUpperCase( Locale l ) version should be better.
http://findbugs.sourceforge.net/bugDescriptions.html#DM_CONVERT_CASE

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/BruceKuiLiu/commons-lang master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/297.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #297


commit ac6ea81247282d7fd929195040acf333cebc7b80
Author: Kui LIU 
Date:   2017-10-09T14:01:42Z

Add a rule of Locale.ENGLISH to String.toUpperCase() method.

A String is being converted to upper case, using the platform's default 
encoding.
This may result in improper conversions when used with international 
characters.
Use the String.toUpperCase( Locale l ) version should be better.
http://findbugs.sourceforge.net/bugDescriptions.html#DM_CONVERT_CASE




---


[jira] [Commented] (RNG-37) Ziggurat algorithm

2017-10-09 Thread Gilles (JIRA)

[ 
https://issues.apache.org/jira/browse/RNG-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196960#comment-16196960
 ] 

Gilles commented on RNG-37:
---

Sorry for the delay.
Bruno, thanks a lot for the review and advice. :)
Olga, alternatively to a pull request, you could also attach patches to this 
report, (or the whole source, since it is a new file).


> Ziggurat algorithm
> --
>
> Key: RNG-37
> URL: https://issues.apache.org/jira/browse/RNG-37
> Project: Commons RNG
>  Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
>
> Fast algorithm for sampling a Gaussian distribution: 
> https://en.wikipedia.org/wiki/Ziggurat_algorithm



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


[jira] [Created] (DAEMON-376) Update Daemon to also search registry for JRE with Java 9 JRE location

2017-10-09 Thread Mark Thomas (JIRA)
Mark Thomas created DAEMON-376:
--

 Summary: Update Daemon to also search registry for JRE with Java 9 
JRE location
 Key: DAEMON-376
 URL: https://issues.apache.org/jira/browse/DAEMON-376
 Project: Commons Daemon
  Issue Type: Bug
 Environment: Windows only
Reporter: Mark Thomas


Java 9:
HKLM\SOFTWARE\JavaSoft\JRE

Java 8 and earlier:
HKLM\SOFTWARE\JavaSoft\Java Runtime Environment



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


[jira] [Commented] (RNG-37) Ziggurat algorithm

2017-10-09 Thread Bruno P. Kinoshita (JIRA)

[ 
https://issues.apache.org/jira/browse/RNG-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196788#comment-16196788
 ] 

Bruno P. Kinoshita commented on RNG-37:
---

Submitted some comments to the pull request. But I think it's not a fork of the 
Commons RNG component? But a repository under your user?

You need to fork the Apache project (here 
https://github.com/apache/commons-rng, there should be a button at the top 
right corner "Fork"). That will create a new repository under your user account 
(https://github.com/cur4so/commons-rng by default). Then you can create a 
branch, and send your pull request, following instructions from some tutorial 
like this one https://biologyguy.github.io/git-novice/09-pull-request/ or this 
one https://help.github.com/articles/creating-a-pull-request-from-a-fork/

Hope it helps,
Bruno

> Ziggurat algorithm
> --
>
> Key: RNG-37
> URL: https://issues.apache.org/jira/browse/RNG-37
> Project: Commons RNG
>  Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
>
> Fast algorithm for sampling a Gaussian distribution: 
> https://en.wikipedia.org/wiki/Ziggurat_algorithm



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


[jira] [Commented] (LOGGING-165) Add Automatic-Module-Name Manifest Header for Java 9 compatibility

2017-10-09 Thread JIRA

[ 
https://issues.apache.org/jira/browse/LOGGING-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196601#comment-16196601
 ] 

陈宝仪 commented on LOGGING-165:
-

Hi 
I tested the jar build from trunk.
This is works for me.
I cant see the maven warning now.

> Add Automatic-Module-Name Manifest Header for Java 9 compatibility
> --
>
> Key: LOGGING-165
> URL: https://issues.apache.org/jira/browse/LOGGING-165
> Project: Commons Logging
>  Issue Type: Improvement
>Affects Versions: 1.2
>Reporter: 陈宝仪
> Fix For: 1.2.1
>
>
>  Ading modularity headers so that other module can import it
> [My project|https://github.com/leonchen83/redis-replicator] using 
> commons-logging as dependency. 
> When I use maven build my project. shows following warning:
> [INFO] --- maven-compiler-plugin:3.7.0:compile (default-compile) @ 
> redis-replicator ---
> [WARNING] 
> 
> [WARNING] * Required filename-based automodules detected. Please don't 
> publish this project to a public artifact repository! *
> [WARNING] 
> 
> The root cause is commons-logging-1.2 is not a standard java 9 module(miss 
> module-info.java). 
> Env:
> java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)



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


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

2017-10-09 Thread Bruno P. Kinoshita (JIRA)

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

Bruno P. Kinoshita commented on LANG-1352:
--

Hi [~Enigo],

There is! I was about to do it, but I think it would be better if you did it :-)

The best way to speed it up, would be writing to [Commons Developer 
list](https://commons.apache.org/mail-lists.html). Read this page about the 
lists, remember to add [lang] as prefix to your e-mail subject, and write 
asking for feedback.

I've already gave my vote as neutral. So if you can get one or two other 
commons developers to review it, it will definitely speed it up.

You can comment not only on your issues, but you can also comment on vote 
threads (though your vote is not binding), other issues, give your perspective 
as user, etc.

Let me know if you need some help with it.
Bruno

> 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
>
> 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)