[jira] [Commented] (RNG-37) Ziggurat algorithm
[ 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
[ 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...
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
[ 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
[ 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"; > MapvalueMap = 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
[ 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"; > MapvalueMap = 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 #:
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 #:
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(...
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
[ 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
[ 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)
[ 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
[ 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)
[ 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)
[ 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(...
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)
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
[ 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(...
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...
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
[ 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
[ 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
[ 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
[ 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...
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...
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 LIUDate: 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
[ 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...
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...
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...
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...
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 LIUDate: 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...
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(...
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(...
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
[ 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(...
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(...
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(...
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(...
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(...
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(...
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...
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 LIUDate: 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
[ 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
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
[ 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
[ 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
[ 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)