[jira] [Comment Edited] (SANDBOX-492) Create StringDistanceFrom class that contains a StringMetric and the left side string. This would have a method that accepts the right side string to test.
[ https://issues.apache.org/jira/browse/SANDBOX-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14375906#comment-14375906 ] Jonathan Baker edited comment on SANDBOX-492 at 3/23/15 1:56 PM: - Pulled in SANDBOX-491 and SANDBOX-493 into SANDBOX-492 and finished unit tests. Please review. Thank you. was (Author: jbaker): Pulled in SANDBOX-491 and SANDBOX-493 into SANDBO-492 and finished unit tests. Please review. Thank you. Create StringDistanceFrom class that contains a StringMetric and the left side string. This would have a method that accepts the right side string to test. Key: SANDBOX-492 URL: https://issues.apache.org/jira/browse/SANDBOX-492 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SANDBOX-492) Create StringDistanceFrom class that contains a StringMetric and the left side string. This would have a method that accepts the right side string to test.
[ https://issues.apache.org/jira/browse/SANDBOX-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14375906#comment-14375906 ] Jonathan Baker edited comment on SANDBOX-492 at 3/23/15 1:56 PM: - Pulled in SANDBOX-491 and SANDBOX-493 into SANDBO-492 and finished unit tests. Please review. Thank you. was (Author: jbaker): Pulled in SANDBOX-491 and SANDBOX0493 into SANDBO-492 and finished unit tests. Please review. Thank you. Create StringDistanceFrom class that contains a StringMetric and the left side string. This would have a method that accepts the right side string to test. Key: SANDBOX-492 URL: https://issues.apache.org/jira/browse/SANDBOX-492 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SANDBOX-492) Create StringDistanceFrom class that contains a StringMetric and the left side string. This would have a method that accepts the right side string to test.
[ https://issues.apache.org/jira/browse/SANDBOX-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14375906#comment-14375906 ] Jonathan Baker commented on SANDBOX-492: Pulled in SANDBOX-491 and SANDBOX0493 into SANDBO-492 and finished unit tests. Please review. Thank you. Create StringDistanceFrom class that contains a StringMetric and the left side string. This would have a method that accepts the right side string to test. Key: SANDBOX-492 URL: https://issues.apache.org/jira/browse/SANDBOX-492 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SANDBOX-492) Create StringDistanceFrom class that contains a StringMetric and the left side string. This would have a method that accepts the right side string to test.
[ https://issues.apache.org/jira/browse/SANDBOX-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14347578#comment-14347578 ] Jonathan Baker commented on SANDBOX-492: WIP: https://github.com/j--baker/commons-text/tree/SANDBOX-492 I'll create a pull request when SANDBOX-491 has been merged into master. Then I'll be able to add a few more unit tests for FuzzyScore and LevenshteinDistance. Create StringDistanceFrom class that contains a StringMetric and the left side string. This would have a method that accepts the right side string to test. Key: SANDBOX-492 URL: https://issues.apache.org/jira/browse/SANDBOX-492 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SANDBOX-493) Change (R) StringMetric.compare(CS left, CS right) to apply so that it is consistent with BiFunction.
[ https://issues.apache.org/jira/browse/SANDBOX-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345020#comment-14345020 ] Jonathan Baker commented on SANDBOX-493: Thanks to you both. I was thinking the same things. 1. I wanted to make sure it was OK to switch from the more meaningful compare to the more abstract-able apply. 2. Should I switch them all to BiFunction (Java 8) as part of this ticket? Running mvn test against 1.8.0_31 64 bit Java (Win 7 Pro 64) worked OK. Please confirm since I don't want to anger any torch-wielding mobs of pre-8 Java users. :) (Disclosure: Our shop is using Java 6, and a mvn test failed for me using 1.6.0_45. :( ) Change (R) StringMetric.compare(CS left, CS right) to apply so that it is consistent with BiFunction. --- Key: SANDBOX-493 URL: https://issues.apache.org/jira/browse/SANDBOX-493 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor Whenever commons-text supports Java 8, StringMetricR should extend BiFunctionCharSequence, CharSequence, R. Renaming compare to apply now will make that transition smoother later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SANDBOX-491) Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance.
[ https://issues.apache.org/jira/browse/SANDBOX-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345551#comment-14345551 ] Jonathan Baker commented on SANDBOX-491: Sent [pull request #1](https://github.com/apache/commons-text/pull/1). Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance. - Key: SANDBOX-491 URL: https://issues.apache.org/jira/browse/SANDBOX-491 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SANDBOX-491) Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance.
[ https://issues.apache.org/jira/browse/SANDBOX-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14344991#comment-14344991 ] Jonathan Baker commented on SANDBOX-491: Thanks. I will. I don't keep up on the mailing lists, so I wanted to make sure it wasn't removed on purpose. Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance. - Key: SANDBOX-491 URL: https://issues.apache.org/jira/browse/SANDBOX-491 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SANDBOX-493) Change (R) StringMetric.compare(CS left, CS right) to apply so that it is consistent with BiFunction.
Jonathan Baker created SANDBOX-493: -- Summary: Change (R) StringMetric.compare(CS left, CS right) to apply so that it is consistent with BiFunction. Key: SANDBOX-493 URL: https://issues.apache.org/jira/browse/SANDBOX-493 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor Whenever commons-text supports Java 8, StringMetricR should extend BiFunctionCharSequence, CharSequence, R. Renaming compare to apply now will make that transition smoother later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SANDBOX-491) Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance.
[ https://issues.apache.org/jira/browse/SANDBOX-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14343563#comment-14343563 ] Jonathan Baker commented on SANDBOX-491: Hi Bruno, Do you know why [non-threshold version](https://commons.apache.org/proper/commons-lang/javadocs/api-3.3/org/apache/commons/lang3/StringUtils.html#getLevenshteinDistance%28java.lang.CharSequence,%20java.lang.CharSequence%29) of the Levenshtein distance was removed when commons-test was spawned from commons-lang3? The commons-text version is just delegating to the other method with Integer.MAX_VALUE. The two commons-lang3 methods were different. Would it make sense to bring it back for use when threshold is set null? Thanks Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance. - Key: SANDBOX-491 URL: https://issues.apache.org/jira/browse/SANDBOX-491 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SANDBOX-492) Create StringDistanceFrom class that contains a StringMetric and the left side string. This would have a method that accepts the right side string to test.
Jonathan Baker created SANDBOX-492: -- Summary: Create StringDistanceFrom class that contains a StringMetric and the left side string. This would have a method that accepts the right side string to test. Key: SANDBOX-492 URL: https://issues.apache.org/jira/browse/SANDBOX-492 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SANDBOX-491) Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance.
[ https://issues.apache.org/jira/browse/SANDBOX-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14342234#comment-14342234 ] Jonathan Baker commented on SANDBOX-491: Please see some (outdated) example code attached to [LANG-1011](https://issues.apache.org/jira/browse/LANG-1011). Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance. - Key: SANDBOX-491 URL: https://issues.apache.org/jira/browse/SANDBOX-491 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SANDBOX-491) Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance.
Jonathan Baker created SANDBOX-491: -- Summary: Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance. Key: SANDBOX-491 URL: https://issues.apache.org/jira/browse/SANDBOX-491 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SANDBOX-491) Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance.
[ https://issues.apache.org/jira/browse/SANDBOX-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14342234#comment-14342234 ] Jonathan Baker edited comment on SANDBOX-491 at 3/1/15 2:10 PM: Please see some (outdated) example code attached to LANG-1011. was (Author: jbaker): Please see some (outdated) example code attached to [LANG-1011](https://issues.apache.org/jira/browse/LANG-1011). Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance. - Key: SANDBOX-491 URL: https://issues.apache.org/jira/browse/SANDBOX-491 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SANDBOX-492) Create StringDistanceFrom class that contains a StringMetric and the left side string. This would have a method that accepts the right side string to test.
[ https://issues.apache.org/jira/browse/SANDBOX-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14342235#comment-14342235 ] Jonathan Baker commented on SANDBOX-492: Please see some (outdated) example code attached to LANG-1011. Create StringDistanceFrom class that contains a StringMetric and the left side string. This would have a method that accepts the right side string to test. Key: SANDBOX-492 URL: https://issues.apache.org/jira/browse/SANDBOX-492 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SANDBOX-491) Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance.
[ https://issues.apache.org/jira/browse/SANDBOX-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14342353#comment-14342353 ] Jonathan Baker commented on SANDBOX-491: I will try to get something together as a github pull request soon. I just wanted to make sure the suggestion passed a sanity test. Thanks for reviewing. Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance. - Key: SANDBOX-491 URL: https://issues.apache.org/jira/browse/SANDBOX-491 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SANDBOX-492) Create StringDistanceFrom class that contains a StringMetric and the left side string. This would have a method that accepts the right side string to test.
[ https://issues.apache.org/jira/browse/SANDBOX-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14342355#comment-14342355 ] Jonathan Baker commented on SANDBOX-492: Thank you. I'll try to put something concrete together soon. Create StringDistanceFrom class that contains a StringMetric and the left side string. This would have a method that accepts the right side string to test. Key: SANDBOX-492 URL: https://issues.apache.org/jira/browse/SANDBOX-492 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1011) Create a new class StringDistance as host for the getXXDistance methods in StringUtils
[
https://issues.apache.org/jira/browse/LANG-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14341562#comment-14341562
]
Jonathan Baker commented on LANG-1011:
--
1. Is org.apache.commons.lang3.text.StringDistances a good place to move these
functions?
2. Should the corresponding changes also be made in the 2.x version? The
[release
plan](https://issues.apache.org/jira/browse/LANG?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel#pd-desc)
says no, but please confirm.
3. Would it make sense (maybe for lang 4 since java 8 is required) to create a
StringDistanceDISTANCE interface that extends [BiFunctionCharSequence,
CharSequence,
DISTANCE](http://docs.oracle.com/javase/8/docs/api/java/util/function/BiFunction.html)?
// For example:
public interface StringDistanceDISTANCE extends BiFunctionCharSequence,
CharSequence, DISTANCE {
public DISTANCE apply( CharSequence t, CharSequence u );
}
public class LevenshteinDistance implements StringDistanceInteger {
private final Integer threshold;
public LeveshteinDistance() { ... }
public LevenshteinDistance( final int threshold ) { ... }
public Integer apply( CharSequence t, CharSequence u ) {
// Would two Leveshtein classes be better than the null check?
if (threshold == null) {
return getDistance( t, u );
} else {
return getDistance( t, u, threshold );
}
}
public static Integer getDistance( CharSequence t, CharSequence u ) {
... }
public static Integer getDistance( CharSequence t, CharSequence u, int
threshold ) { ... }
}
Create a new class StringDistance as host for the getXXDistance methods in
StringUtils
--
Key: LANG-1011
URL: https://issues.apache.org/jira/browse/LANG-1011
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Benedikt Ritter
Assignee: Benedikt Ritter
Fix For: 3.4
We're getting more and more algorithms that calculate distances between
strings, so it makes sense to create a new class for this kind of logic.
deprecate getLevenshteinDistance and getJaroWinklerDistance and delegate to
the new class. If the new class is implemented in 3.4, move getFuzzyDistance
(is has not yet been released)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (LANG-1011) Create a new class StringDistance as host for the getXXDistance methods in StringUtils
[
https://issues.apache.org/jira/browse/LANG-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14341562#comment-14341562
]
Jonathan Baker edited comment on LANG-1011 at 2/28/15 5:45 PM:
---
1. Is org.apache.commons.lang3.text.StringDistances a good place to move these
functions?
2. Should the corresponding changes also be made in the 2.x version? The
[release
plan](https://issues.apache.org/jira/browse/LANG?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel#pd-desc)
says no, but please confirm.
was (Author: jbaker):
1. Is org.apache.commons.lang3.text.StringDistances a good place to move these
functions?
2. Should the corresponding changes also be made in the 2.x version? The
[release
plan](https://issues.apache.org/jira/browse/LANG?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel#pd-desc)
says no, but please confirm.
3. Would it make sense (maybe for lang 4 since java 8 is required) to create a
StringDistanceDISTANCE interface that extends [BiFunctionCharSequence,
CharSequence,
DISTANCE](http://docs.oracle.com/javase/8/docs/api/java/util/function/BiFunction.html)?
// For example:
public interface StringDistanceDISTANCE extends BiFunctionCharSequence,
CharSequence, DISTANCE {
public DISTANCE apply( CharSequence t, CharSequence u );
}
public class LevenshteinDistance implements StringDistanceInteger {
private final Integer threshold;
public LeveshteinDistance() { ... }
public LevenshteinDistance( final int threshold ) { ... }
public Integer apply( CharSequence t, CharSequence u ) {
// Would two Leveshtein classes be better than the null check?
if (threshold == null) {
return getDistance( t, u );
} else {
return getDistance( t, u, threshold );
}
}
public static Integer getDistance( CharSequence t, CharSequence u ) {
... }
public static Integer getDistance( CharSequence t, CharSequence u, int
threshold ) { ... }
}
Create a new class StringDistance as host for the getXXDistance methods in
StringUtils
--
Key: LANG-1011
URL: https://issues.apache.org/jira/browse/LANG-1011
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Benedikt Ritter
Assignee: Benedikt Ritter
Fix For: 3.4
We're getting more and more algorithms that calculate distances between
strings, so it makes sense to create a new class for this kind of logic.
deprecate getLevenshteinDistance and getJaroWinklerDistance and delegate to
the new class. If the new class is implemented in 3.4, move getFuzzyDistance
(is has not yet been released)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (LANG-1011) Create a new class StringDistance as host for the getXXDistance methods in StringUtils
[ https://issues.apache.org/jira/browse/LANG-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Baker updated LANG-1011: - Comment: was deleted (was: Please ignore #3. My Java 8 ignorance is showing. I should have taken the time to do a test *before* posting. Sorry!) Create a new class StringDistance as host for the getXXDistance methods in StringUtils -- Key: LANG-1011 URL: https://issues.apache.org/jira/browse/LANG-1011 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Benedikt Ritter Assignee: Benedikt Ritter Fix For: 3.4 We're getting more and more algorithms that calculate distances between strings, so it makes sense to create a new class for this kind of logic. deprecate getLevenshteinDistance and getJaroWinklerDistance and delegate to the new class. If the new class is implemented in 3.4, move getFuzzyDistance (is has not yet been released) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1011) Create a new class StringDistance as host for the getXXDistance methods in StringUtils
[ https://issues.apache.org/jira/browse/LANG-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14341685#comment-14341685 ] Jonathan Baker commented on LANG-1011: -- Please ignore #3. My Java 8 ignorance is showing. I should have taken the time to do a test *before* posting. Sorry! Create a new class StringDistance as host for the getXXDistance methods in StringUtils -- Key: LANG-1011 URL: https://issues.apache.org/jira/browse/LANG-1011 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Benedikt Ritter Assignee: Benedikt Ritter Fix For: 3.4 We're getting more and more algorithms that calculate distances between strings, so it makes sense to create a new class for this kind of logic. deprecate getLevenshteinDistance and getJaroWinklerDistance and delegate to the new class. If the new class is implemented in 3.4, move getFuzzyDistance (is has not yet been released) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1011) Create a new class StringDistance as host for the getXXDistance methods in StringUtils
[ https://issues.apache.org/jira/browse/LANG-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Baker updated LANG-1011: - Attachment: StringDistanceTest5.java More fun with functions. :) With a StringDistanceDISTANCE, made a StringDistanceFrom class which is set up with the algorithm and the left side string. It can be used to iterate over a list of right side strings and spit out the differences. Create a new class StringDistance as host for the getXXDistance methods in StringUtils -- Key: LANG-1011 URL: https://issues.apache.org/jira/browse/LANG-1011 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Benedikt Ritter Assignee: Benedikt Ritter Fix For: 3.4 Attachments: StringDistanceTest4.java, StringDistanceTest4Pre8.java, StringDistanceTest5.java We're getting more and more algorithms that calculate distances between strings, so it makes sense to create a new class for this kind of logic. deprecate getLevenshteinDistance and getJaroWinklerDistance and delegate to the new class. If the new class is implemented in 3.4, move getFuzzyDistance (is has not yet been released) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1011) Create a new class StringDistance as host for the getXXDistance methods in StringUtils
[ https://issues.apache.org/jira/browse/LANG-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Baker updated LANG-1011: - Attachment: StringDistanceTest4Pre8.java StringDistanceTest4.java (Warning: thinking out loud; java 8 noob; too much coffee) 3. Would it make sense to break out implementations into their own classes? Some of the methods have other parameters besides the two CharSequences being compared. These would be delegated to from StringDistances class. 4. Would it make sense to have those classes all implement StringDistanceDISTANCE, which would extend BiFunctionCharSequence, CharSequence, DISTANCE when java 8 is supported? With #3 and #4, the various algorithms could be used interchangeably, even if some require some initial configuration. Create a new class StringDistance as host for the getXXDistance methods in StringUtils -- Key: LANG-1011 URL: https://issues.apache.org/jira/browse/LANG-1011 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Benedikt Ritter Assignee: Benedikt Ritter Fix For: 3.4 Attachments: StringDistanceTest4.java, StringDistanceTest4Pre8.java We're getting more and more algorithms that calculate distances between strings, so it makes sense to create a new class for this kind of logic. deprecate getLevenshteinDistance and getJaroWinklerDistance and delegate to the new class. If the new class is implemented in 3.4, move getFuzzyDistance (is has not yet been released) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1055) StrSubstitutor.replaceSystemProperties does not work constistently
[
https://issues.apache.org/jira/browse/LANG-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286057#comment-14286057
]
Jonathan Baker commented on LANG-1055:
--
Not sure if this is correct, or if it addresses Phil's concerns, but the
following is an implementation that 1) does not use a singleton, and 2) allows
each instance to have their own snap-shop of the system properties:
https://github.com/apache/commons-lang/pull/43
Thanks in advance for your time.
StrSubstitutor.replaceSystemProperties does not work constistently
--
Key: LANG-1055
URL: https://issues.apache.org/jira/browse/LANG-1055
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Environment: Windows 7, Java 7
Reporter: Phil Dicke
StrSubsitutor caches a references to SystemProperties statically on first
class references. This does not work properly with System.setProperties().
For example the following code:
{code}
package test.utilities;
import java.util.Properties;
import org.apache.commons.lang.text.StrSubstitutor;
public class TestStrSubstitutor {
public static void main(String[] args) {
System.out.println(StrSubstitutor.replaceSystemProperties(os.name=${os.name}));
Properties testProps = new Properties();
testProps.put(test_key, test_value);
testProps.putAll(System.getProperties());
System.setProperties(testProps);
System.out.println(StrSubstitutor.replace(test_key=${test_key},
System.getProperties()));
System.out.println(StrSubstitutor.replaceSystemProperties(test_key=${test_key}));
}
}
{code}
produces the following output:
{code}
os.name=Windows 7
test_key=test_value
test_key=${test_key}
{code}
The code linked here shows the static caching of the System Properties
reference:
http://commons.apache.org/proper/commons-lang/apidocs/src-html/org/apache/commons/lang3/text/StrLookup.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1082) Add option to disable the objectsTriviallyEqual test in DiffBuilder.
[
https://issues.apache.org/jira/browse/LANG-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286579#comment-14286579
]
Jonathan Baker commented on LANG-1082:
--
I'd be happy to throw some code out there, but I want to make sure I'm
preserving the original spirit.
My gut tells me DiffBuilder should remain immutable.
Would adding a second constructor be the best fit?
public DiffBuilder( boolean testTriviallyEqual ) { ... }
public DiffBuilder() { this( true ); }
Thoughts?
Add option to disable the objectsTriviallyEqual test in DiffBuilder.
--
Key: LANG-1082
URL: https://issues.apache.org/jira/browse/LANG-1082
Project: Commons Lang
Issue Type: Improvement
Components: lang.builder.*
Affects Versions: 3.3.2
Reporter: Jonathan Baker
Priority: Trivial
Fix For: Patch Needed
Original Estimate: 0.25h
Remaining Estimate: 0.25h
For example, a bean (e.g. a JPA record) has equals() overridden with a
implementation that tests its id property. If two beans have the same ID,
they correspond to the same record in the database. However, without
tricking the objectsTriviallyEqual check in the DiffBuilder constructor,
there is no way to build a DiffResult using before and after instances
with changes to other properties (name, modification time, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1083) Add (T) casts to get unit tests to pass in old JDK.
[ https://issues.apache.org/jira/browse/LANG-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14283783#comment-14283783 ] Jonathan Baker commented on LANG-1083: -- Created PR https://github.com/apache/commons-lang/pull/42 Add (T) casts to get unit tests to pass in old JDK. --- Key: LANG-1083 URL: https://issues.apache.org/jira/browse/LANG-1083 Project: Commons Lang Issue Type: Bug Environment: Maven 3.2.5, Java 1.6.0_18, Fedora 11, AMD 64 (2.6.30.10-105.2.23.fc11.x86_64) Reporter: Jonathan Baker Priority: Trivial This is probably just a quirk of the old JDK that was used. The casts are not necessary on other computers, but they don't seem to hurt either. (Please verify that of course!) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (LANG-1083) Add (T) casts to get unit tests to pass in old JDK.
Jonathan Baker created LANG-1083: Summary: Add (T) casts to get unit tests to pass in old JDK. Key: LANG-1083 URL: https://issues.apache.org/jira/browse/LANG-1083 Project: Commons Lang Issue Type: Bug Environment: Maven 3.2.5, Java 1.6.0_18, Fedora 11, AMD 64 (2.6.30.10-105.2.23.fc11.x86_64) Reporter: Jonathan Baker Priority: Trivial This is probably just a quirk of the old JDK that was used. The casts are not necessary on other computers, but they don't seem to hurt either. (Please verify that of course!) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1081) DiffBuilder.append(String, Object left, Object right) does not do a left.equals(right) check.
[ https://issues.apache.org/jira/browse/LANG-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281840#comment-14281840 ] Jonathan Baker commented on LANG-1081: -- Submitted a pull request on GitHub.com. I hope this is the correct procedure. Please advise. DiffBuilder.append(String, Object left, Object right) does not do a left.equals(right) check. - Key: LANG-1081 URL: https://issues.apache.org/jira/browse/LANG-1081 Project: Commons Lang Issue Type: Bug Components: lang.builder.* Affects Versions: 3.3.2 Reporter: Jonathan Baker Priority: Trivial Attachments: DiffBuilder-equals_test_in_append_Objects.patch, DiffBuilderAppendsNonEqualObjects.java, DiffBuilderAppendsNonEqualObjectsFixed.java Original Estimate: 1m Remaining Estimate: 1m Only testing == without testing equals() seems wrong. Should an equals() test be added after determining that the parameters are not arrays? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (LANG-1081) DiffBuilder.append(String, Object left, Object right) does not do a left.equals(right) check.
Jonathan Baker created LANG-1081: Summary: DiffBuilder.append(String, Object left, Object right) does not do a left.equals(right) check. Key: LANG-1081 URL: https://issues.apache.org/jira/browse/LANG-1081 Project: Commons Lang Issue Type: Bug Components: lang.builder.* Affects Versions: 3.3.2 Reporter: Jonathan Baker Priority: Trivial Only testing == without testing equals() seems wrong. Should an equals() test be added after determining that the parameters are not arrays? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (LANG-1082) Allow the objectsTriviallyEqual test to be disabled.
Jonathan Baker created LANG-1082: Summary: Allow the objectsTriviallyEqual test to be disabled. Key: LANG-1082 URL: https://issues.apache.org/jira/browse/LANG-1082 Project: Commons Lang Issue Type: Improvement Components: lang.builder.* Affects Versions: 3.3.2 Reporter: Jonathan Baker Priority: Trivial For example, a bean (e.g. a JPA record) has equals() overridden with a implementation that tests its id property. If two beans have the same ID, they correspond to the same record in the database. However, without tricking the objectsTriviallyEqual check in the DiffBuilder constructor, there is no way to build a DiffResult using before and after instances with changes to other properties (name, modification time, etc). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1081) DiffBuilder.append(String, Object left, Object right) does not do a left.equals(right) check.
[ https://issues.apache.org/jira/browse/LANG-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Baker updated LANG-1081: - Attachment: DiffBuilder-equals_test_in_append_Objects.patch DiffBuilderAppendsNonEqualObjectsFixed.java DiffBuilderAppendsNonEqualObjects.java Attached are examples of how to detect and correct the issue. DiffBuilder.append(String, Object left, Object right) does not do a left.equals(right) check. - Key: LANG-1081 URL: https://issues.apache.org/jira/browse/LANG-1081 Project: Commons Lang Issue Type: Bug Components: lang.builder.* Affects Versions: 3.3.2 Reporter: Jonathan Baker Priority: Trivial Attachments: DiffBuilder-equals_test_in_append_Objects.patch, DiffBuilderAppendsNonEqualObjects.java, DiffBuilderAppendsNonEqualObjectsFixed.java Original Estimate: 1m Remaining Estimate: 1m Only testing == without testing equals() seems wrong. Should an equals() test be added after determining that the parameters are not arrays? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1082) Add option to disable the objectsTriviallyEqual test in DiffBuilder.
[ https://issues.apache.org/jira/browse/LANG-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Baker updated LANG-1082: - Summary: Add option to disable the objectsTriviallyEqual test in DiffBuilder. (was: Allow the objectsTriviallyEqual test to be disabled.) Add option to disable the objectsTriviallyEqual test in DiffBuilder. -- Key: LANG-1082 URL: https://issues.apache.org/jira/browse/LANG-1082 Project: Commons Lang Issue Type: Improvement Components: lang.builder.* Affects Versions: 3.3.2 Reporter: Jonathan Baker Priority: Trivial Original Estimate: 0.25h Remaining Estimate: 0.25h For example, a bean (e.g. a JPA record) has equals() overridden with a implementation that tests its id property. If two beans have the same ID, they correspond to the same record in the database. However, without tricking the objectsTriviallyEqual check in the DiffBuilder constructor, there is no way to build a DiffResult using before and after instances with changes to other properties (name, modification time, etc). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] Created: (NET-290) DotTerminatedMessageReader does not parse \r \r \n correctly
DotTerminatedMessageReader does not parse \r \r \n correctly
Key: NET-290
URL: https://issues.apache.org/jira/browse/NET-290
Project: Commons Net
Issue Type: Bug
Affects Versions: 2.0
Environment: RedHat Linux
Linux XXX 2.6.18-128.2.1.el5 #1 SMP Wed Jul 8 11:54:47 EDT 2009 x86_64 x86_64
x86_64 GNU/Linux
java version 1.6.0
OpenJDK Runtime Environment (build 1.6.0-b09)
OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)
Reporter: Jonathan Baker
If the DotTerminatedMessageReader receives two carriage return characters at
the end of the line, it does not process them correctly.
When the DTMR tries to read \r\r\n from the server, it does not process this
as a correct end of line. The code handles the first \r as a standalone
character, but then does not process the second \r character to test for
end-of-line. If this happens at the end of a file, the DTMR will not recognize
the '.' character as the end of file, and will try to read another character.
This hangs the reader.
The process flow breaks down in the following order. The first \r character is
tested at line 127. It then reads the second \r character at line 133. The
test fails, and the second \r is pushed in to the internalBuffer at line 160.
The second time the read() method is called, the \r character is returned
without processing at line 90. The third time the read() is called, the \n
character is read and checked at line 127. But, because the preceding \r
character is not found first, it does not process this as EOL. If the next
character is a '.', it is not processed as EOF.
The following fix solves the problem by pushing the second \r character back in
to the reader stream (rather than putting it in the internalBuffer), where it
will be processed correctly:
160a160,163
else if ( ch == '\r' )
{
internalReader.unread( ch );
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
