[GitHub] commons-lang issue #189: new impl of LevenshteinDistance
Github user yufcuy commented on the issue: https://github.com/apache/commons-lang/pull/189 Hello, @britter @kinow The details of Levenshtein distance can be find at https://en.wikipedia.org/wiki/Levenshtein_distance, as it describe, the algorithm is compute a matrix to hold the Levenshtein distances between all prefixes of the first string and all prefixes of the second. For all i and j, d[i][j] will hold the Levenshtein distance between the first i characters of s and the first j characters of t. The previous impl use two matrix rows for the construction. When we calculate the value of d[i][j] we find only the value of d[i-1][j-1], d[i-1][j] and d[i][j-1] are used according to the algorithm. And we use a matrix row p[] for the construction, when calculate p[j] at the ith iteration, it actually calculate the value of d[i][j], and only d[i-1][j-1] is covered by p[j-1], so we use variable 'upper_left' to hold d[i-1][j-1], and use variable 'upper' to hold next 'upper_left'. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (LANG-1267) FastDateFormat does not support timezone X/XX/XXX in SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-1267:
--
Fix Version/s: Patch Needed
> FastDateFormat does not support timezone X/XX/XXX in SimpleDateFormat
> -
>
> Key: LANG-1267
> URL: https://issues.apache.org/jira/browse/LANG-1267
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.3.2
>Reporter: Hyukjin Kwon
> Fix For: Patch Needed, 3.6
>
>
> It sees {{FastDateFormat}} does not support timezone {{X}}/{{XX}}/{{XXX}} in
> {{SimpleDateFormat}}.
> For example,
> {code}
> new FastDateFormat("-MM-dd'T'HH:mm:ss.SSSXXX")
> {code}
> throws an exception as below:
> {code}
> Illegal pattern component: XXX
> java.lang.IllegalArgumentException: Illegal pattern component: XXX
> at
> org.apache.commons.lang3.time.FastDatePrinter.parsePattern(FastDatePrinter.java:282)
> at
> org.apache.commons.lang3.time.FastDatePrinter.init(FastDatePrinter.java:149)
> at
> org.apache.commons.lang3.time.FastDatePrinter.(FastDatePrinter.java:142)
> {code}
> {{X}}/{{XX}}/{{XXX}} are different with {{Z}} or {{ZZ}} as described in
> https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html#iso8601timezone
> It supports to read all {{+0800}}, {{+08}} and {{+08:00}} whereas it seems
> there is no way to include those all.
> I looked though the documentation multiple times but I could not find the
> explicit mention about this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1263) Add possibility to retrieve the current JavaVersion
[ https://issues.apache.org/jira/browse/LANG-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15499224#comment-15499224 ] ASF GitHub Bot commented on LANG-1263: -- Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/187 [](https://coveralls.io/builds/7932625) Coverage increased (+0.007%) to 93.57% when pulling **dedddbd8df9791cf644c5ec3c8c2f7806e9cad21 on britter:LANG-1263** into **49e8d539fb248b9dff23e2c5b0766c0f966cee64 on apache:master**. > Add possibility to retrieve the current JavaVersion > --- > > Key: LANG-1263 > URL: https://issues.apache.org/jira/browse/LANG-1263 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > Fix For: 3.5 > > > Currently one has to iterate over all JavaVersion enum values and compare > them to the value of java.specification.version in order to get the current > JavaVersion enum value. > Provide a convenient method for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] commons-lang issue #187: LANG-1263 Add possibility to retrieve the current J...
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/187 [](https://coveralls.io/builds/7932625) Coverage increased (+0.007%) to 93.57% when pulling **dedddbd8df9791cf644c5ec3c8c2f7806e9cad21 on britter:LANG-1263** into **49e8d539fb248b9dff23e2c5b0766c0f966cee64 on apache:master**. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1267) FastDateFormat does not support timezone X/XX/XXX in SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15499159#comment-15499159
]
Benedikt Ritter commented on LANG-1267:
---
Patches welcome
> FastDateFormat does not support timezone X/XX/XXX in SimpleDateFormat
> -
>
> Key: LANG-1267
> URL: https://issues.apache.org/jira/browse/LANG-1267
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.3.2
>Reporter: Hyukjin Kwon
> Fix For: 3.6
>
>
> It sees {{FastDateFormat}} does not support timezone {{X}}/{{XX}}/{{XXX}} in
> {{SimpleDateFormat}}.
> For example,
> {code}
> new FastDateFormat("-MM-dd'T'HH:mm:ss.SSSXXX")
> {code}
> throws an exception as below:
> {code}
> Illegal pattern component: XXX
> java.lang.IllegalArgumentException: Illegal pattern component: XXX
> at
> org.apache.commons.lang3.time.FastDatePrinter.parsePattern(FastDatePrinter.java:282)
> at
> org.apache.commons.lang3.time.FastDatePrinter.init(FastDatePrinter.java:149)
> at
> org.apache.commons.lang3.time.FastDatePrinter.(FastDatePrinter.java:142)
> {code}
> {{X}}/{{XX}}/{{XXX}} are different with {{Z}} or {{ZZ}} as described in
> https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html#iso8601timezone
> It supports to read all {{+0800}}, {{+08}} and {{+08:00}} whereas it seems
> there is no way to include those all.
> I looked though the documentation multiple times but I could not find the
> explicit mention about this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1267) FastDateFormat does not support timezone X/XX/XXX in SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-1267:
--
Fix Version/s: 3.6
> FastDateFormat does not support timezone X/XX/XXX in SimpleDateFormat
> -
>
> Key: LANG-1267
> URL: https://issues.apache.org/jira/browse/LANG-1267
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.3.2
>Reporter: Hyukjin Kwon
> Fix For: 3.6
>
>
> It sees {{FastDateFormat}} does not support timezone {{X}}/{{XX}}/{{XXX}} in
> {{SimpleDateFormat}}.
> For example,
> {code}
> new FastDateFormat("-MM-dd'T'HH:mm:ss.SSSXXX")
> {code}
> throws an exception as below:
> {code}
> Illegal pattern component: XXX
> java.lang.IllegalArgumentException: Illegal pattern component: XXX
> at
> org.apache.commons.lang3.time.FastDatePrinter.parsePattern(FastDatePrinter.java:282)
> at
> org.apache.commons.lang3.time.FastDatePrinter.init(FastDatePrinter.java:149)
> at
> org.apache.commons.lang3.time.FastDatePrinter.(FastDatePrinter.java:142)
> {code}
> {{X}}/{{XX}}/{{XXX}} are different with {{Z}} or {{ZZ}} as described in
> https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html#iso8601timezone
> It supports to read all {{+0800}}, {{+08}} and {{+08:00}} whereas it seems
> there is no way to include those all.
> I looked though the documentation multiple times but I could not find the
> explicit mention about this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (LANG-1197) Prepare Java 9 detection
[
https://issues.apache.org/jira/browse/LANG-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter resolved LANG-1197.
---
Resolution: Fixed
Assignee: Benedikt Ritter
Fixed merged in ad1b72b7ece0166c5fbe0c6136213589eeed9945
> Prepare Java 9 detection
>
>
> Key: LANG-1197
> URL: https://issues.apache.org/jira/browse/LANG-1197
> Project: Commons Lang
> Issue Type: Task
> Components: lang.*
>Affects Versions: 3.4
>Reporter: Michael Osipov
>Assignee: Benedikt Ritter
> Fix For: 3.5
>
>
> In anticipation of Java 9 and [JEP 223|http://openjdk.java.net/jeps/223], the
> versioning scheme will change completely. We need to reflect that in
> {{SystemUtils}}, {{JavaVersion}}, etc.:
> * {{SystemUtils}}: Deprecate {{IS_JAVA_1_9}} and replace with {{IS_JAVA_9}}
> * {{JavaVersion}}: Deprecate {{JAVA_1_9}} in {{JavaVersion}} and replace with
> {{JAVA_9}}
> and other places in the library.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1197) Prepare Java 9 detection
[
https://issues.apache.org/jira/browse/LANG-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15499134#comment-15499134
]
ASF GitHub Bot commented on LANG-1197:
--
Github user asfgit closed the pull request at:
https://github.com/apache/commons-lang/pull/163
> Prepare Java 9 detection
>
>
> Key: LANG-1197
> URL: https://issues.apache.org/jira/browse/LANG-1197
> Project: Commons Lang
> Issue Type: Task
> Components: lang.*
>Affects Versions: 3.4
>Reporter: Michael Osipov
> Fix For: 3.5
>
>
> In anticipation of Java 9 and [JEP 223|http://openjdk.java.net/jeps/223], the
> versioning scheme will change completely. We need to reflect that in
> {{SystemUtils}}, {{JavaVersion}}, etc.:
> * {{SystemUtils}}: Deprecate {{IS_JAVA_1_9}} and replace with {{IS_JAVA_9}}
> * {{JavaVersion}}: Deprecate {{JAVA_1_9}} in {{JavaVersion}} and replace with
> {{JAVA_9}}
> and other places in the library.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] commons-lang pull request #163: LANG-1197: Prepare Java 9 detection
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/163 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (LANG-1197) Prepare Java 9 detection
[
https://issues.apache.org/jira/browse/LANG-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-1197:
--
Fix Version/s: 3.5
> Prepare Java 9 detection
>
>
> Key: LANG-1197
> URL: https://issues.apache.org/jira/browse/LANG-1197
> Project: Commons Lang
> Issue Type: Task
> Components: lang.*
>Affects Versions: 3.4
>Reporter: Michael Osipov
> Fix For: 3.5
>
>
> In anticipation of Java 9 and [JEP 223|http://openjdk.java.net/jeps/223], the
> versioning scheme will change completely. We need to reflect that in
> {{SystemUtils}}, {{JavaVersion}}, etc.:
> * {{SystemUtils}}: Deprecate {{IS_JAVA_1_9}} and replace with {{IS_JAVA_9}}
> * {{JavaVersion}}: Deprecate {{JAVA_1_9}} in {{JavaVersion}} and replace with
> {{JAVA_9}}
> and other places in the library.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1110) Implement HashSetvBitSetTest using JMH
[ https://issues.apache.org/jira/browse/LANG-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-1110: -- Fix Version/s: (was: 3.5) 3.6 > Implement HashSetvBitSetTest using JMH > -- > > Key: LANG-1110 > URL: https://issues.apache.org/jira/browse/LANG-1110 > Project: Commons Lang > Issue Type: Test > Components: lang.* >Reporter: Benedikt Ritter > Fix For: Patch Needed, 3.6 > > > HashSetvBitSetTest currently writes to Std out, which is bad practice for > unit tests. Since HashSetvBitSetTest is really a performance test and not a > unit test, we should reimplement it using OpenJMH. The results could then be > published on our website. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
