[jira] [Commented] (BCEL-209) Bug fixes and improvements to InvokeDynamic and BootStrapMethods implementation
[ https://issues.apache.org/jira/browse/BCEL-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14341780#comment-14341780 ] Dave Brosius commented on BCEL-209: --- haven't really tested it, but the approach seems fine to me. > Bug fixes and improvements to InvokeDynamic and BootStrapMethods > implementation > --- > > Key: BCEL-209 > URL: https://issues.apache.org/jira/browse/BCEL-209 > Project: Commons BCEL > Issue Type: Bug >Reporter: Mark Roberts > Attachments: counter.diff, invoke4.diff > > > (Apologies in advance - this is a very large diff.) > During the past year, both the Apache Commons BCEL team and our group here at > the UW independently completed the support for InvokeDynamic . Some things > we chose to do the same way, but there are a few items that are quite > different. Trying not to be too biased, I believe our method is better. One > of the larger differences is your decision to add the abstract class > NameSignatureMethod between FieldOrMethod and CPInstruction and then have > InvokeDynamic extend from that instead of from InvokeInstruction. To me this > seems wrong. In addition to forcing InvokeDynamic to duplicate all the > methods from InvokeInstruction and FieldOrMethod, it is awkward that it is > the only form of the Invoke Instruction that doesn't derive from > InvokeInstruction. > This patch also includes several methods missing from the current > implementation: alternative initializers, toString, and support for the > Visitor paradigm. > There are bug fixes to Constants.java and InstructionFinder.java as well. -- 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 StringDistance, 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-1087) NumberUtils#createNumber() returns positive BigDecimal when negative Float is expected
[
https://issues.apache.org/jira/browse/LANG-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Renat Zhilkibaev updated LANG-1087:
---
Description:
{{NumberUtils.createNumber("-0.0")}} returns {{BigDecimal}} with 0 signum.
Caused by the implementation not checking for sign when extracting mantissa
from the input string.
Expected is that negative {{Float}} is returned.
was:
NumberUtils.createNumber("-0.0") returns BigDecimal with 0 signum.
Caused by the implementation not checking for sign when extracting mantissa
from the input string.
Expected is that negative Float is returned.
> NumberUtils#createNumber() returns positive BigDecimal when negative Float is
> expected
> --
>
> Key: LANG-1087
> URL: https://issues.apache.org/jira/browse/LANG-1087
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.x
>Reporter: Renat Zhilkibaev
> Attachments: lang-1087-patch1.diff
>
>
> {{NumberUtils.createNumber("-0.0")}} returns {{BigDecimal}} with 0 signum.
> Caused by the implementation not checking for sign when extracting mantissa
> from the input string.
> Expected is that negative {{Float}} is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1087) NumberUtils#createNumber() returns positive BigDecimal when negative Float is expected
[
https://issues.apache.org/jira/browse/LANG-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Renat Zhilkibaev updated LANG-1087:
---
Attachment: lang-1087-patch1.diff
Attaching (lang-1087-patch1.diff) a possible fix.
> NumberUtils#createNumber() returns positive BigDecimal when negative Float is
> expected
> --
>
> Key: LANG-1087
> URL: https://issues.apache.org/jira/browse/LANG-1087
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.x
>Reporter: Renat Zhilkibaev
> Attachments: lang-1087-patch1.diff
>
>
> NumberUtils.createNumber("-0.0") returns BigDecimal with 0 signum.
> Caused by the implementation not checking for sign when extracting mantissa
> from the input string.
> Expected is that negative Float is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1087) NumberUtils#createNumber() returns positive BigDecimal when negative Float is expected
[
https://issues.apache.org/jira/browse/LANG-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Renat Zhilkibaev updated LANG-1087:
---
Description:
NumberUtils.createNumber("-0.0") returns BigDecimal with 0 signum.
Caused by the implementation not checking for sign when extracting mantissa
from the input string.
Expected is that negative Float is returned.
was:
NumberUtils.createNumber("-0.0") returns BigDecimal with 0 signum.
Caused by the implementation not checking for sign when extracting mantissa
from the input string.
> NumberUtils#createNumber() returns positive BigDecimal when negative Float is
> expected
> --
>
> Key: LANG-1087
> URL: https://issues.apache.org/jira/browse/LANG-1087
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.x
>Reporter: Renat Zhilkibaev
>
> NumberUtils.createNumber("-0.0") returns BigDecimal with 0 signum.
> Caused by the implementation not checking for sign when extracting mantissa
> from the input string.
> Expected is that negative Float is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (LANG-1087) NumberUtils#createNumber() returns positive BigDecimal when negative Float is expected
Renat Zhilkibaev created LANG-1087:
--
Summary: NumberUtils#createNumber() returns positive BigDecimal
when negative Float is expected
Key: LANG-1087
URL: https://issues.apache.org/jira/browse/LANG-1087
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.x
Reporter: Renat Zhilkibaev
NumberUtils.createNumber("-0.0") returns BigDecimal with 0 signum.
Caused by the implementation not checking for sign when extracting mantissa
from the input string.
--
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 StringDistance, which would extend BiFunction 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] [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-tabpanel&focusedCommentId=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
StringDistance interface that extends [BiFunction](http://docs.oracle.com/javase/8/docs/api/java/util/function/BiFunction.html)?
// For example:
public interface StringDistance extends BiFunction {
public DISTANCE apply( CharSequence t, CharSequence u );
}
public class LevenshteinDistance implements StringDistance {
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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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
StringDistance interface that extends [BiFunction](http://docs.oracle.com/javase/8/docs/api/java/util/function/BiFunction.html)?
// For example:
public interface StringDistance extends BiFunction {
public DISTANCE apply( CharSequence t, CharSequence u );
}
public class LevenshteinDistance implements StringDistance {
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] [Commented] (LANG-1061) FastDateParser error - timezone followed by year
[
https://issues.apache.org/jira/browse/LANG-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14341536#comment-14341536
]
Sebb commented on LANG-1061:
The patch is a clearer now. Still has some spurious white space changes, but
can ignore those.
It will take a bit of time to review this, but it's looking good so far.
> FastDateParser error - timezone followed by year
>
>
> Key: LANG-1061
> URL: https://issues.apache.org/jira/browse/LANG-1061
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.3.2
>Reporter: dmeneses
> Fix For: Review Patch
>
> Attachments:
> 0001-https-issues.apache.org-jira-browse-LANG-1061-FastDa.patch,
> 0001-https-issues.apache.org-jira-browse-LANG-1061-FastDa.patch,
> 0002-https-issues.apache.org-jira-browse-LANG-1061-FastDa.patch
>
>
> The following code throws an exception:
> DateParser dp = FastDateFormat.getInstance("z ", Locale.US);
> dp.parse("GMT+00:00 2010");
> The format works correctly with SimpleDateFormat.
> Stack:
> java.text.ParseException: Unparseable date: "GMT+00:00 2010" does not match
> (GMT[+\-]\d{0,1}\d{2}|[+\-]\d{2}:?\d{2}|\QAcre
> Time\E|\QACT\E|\QADT\E|\QAfghanistan
> Time\E|\QAFT\E|\QAKDT\E|\QAKST\E|\QAlaska Daylight Time\E|\QAlaska Standard
> Time\E|\QAlma-Ata Time\E|\QALMT\E|\QAmazon Summer Time\E|\QAmazon
> Time\E|\QAMST\E|\QAMT\E|\QAnadyr Time\E|\QANAT\E|\QAqtau Time\E|\QAqtobe
> Time\E|\QAQTT\E|\QArabia Standard Time\E|\QArgentine Time\E|\QArmenia
> Time\E|\QART\E|\QAST\E|\QAtlantic Daylight Time\E|\QAtlantic Standard
> Time\E|\QAzerbaijan Summer Time\E|\QAzerbaijan Time\E|\QAzores Summer
> Time\E|\QAzores Time\E|\QAZOST\E|\QAZOT\E|\QAZST\E|\QAZT\E|\QBangladesh
> Time\E|\QBDT\E|\QBhutan Time\E|\QBNT\E|\QBolivia Time\E|\QBOT\E|\QBrasilia
> Summer Time\E|\QBrasilia Time\E|\QBritish Summer
> Time\E|\QBRST\E|\QBRT\E|\QBrunei Time\E|\QBST\E|\QBTT\E|\QCape Verde
> Time\E|\QCAT\E|\QCCT\E|\QCDT\E|\QCentral African Time\E|\QCentral Daylight
> Time\E|\QCentral European Summer Time\E|\QCentral European Time\E|\QCentral
> Indonesia Time\E|\QCentral Standard Time\E|\QCentral Standard Time (Northern
> Territory)\E|\QCentral Standard Time (South Australia)\E|\QCentral Standard
> Time (South Australia/New South Wales)\E|\QCentral Summer Time (South
> Australia)\E|\QCentral Summer Time (South Australia/New South
> Wales)\E|\QCentral Western Standard Time
> (Australia)\E|\QCEST\E|\QCET\E|\QCHADT\E|\QChamorro Standard
> Time\E|\QCHAST\E|\QChatham Daylight Time\E|\QChatham Standard Time\E|\QChile
> Summer Time\E|\QChile Time\E|\QChina Standard Time\E|\QChoibalsan
> Time\E|\QCHOT\E|\QChristmas Island Time\E|\QChST\E|\QCHUT\E|\QChuuk
> Time\E|\QCKT\E|\QCLST\E|\QCLT\E|\QCocos Islands Time\E|\QColombia
> Time\E|\QCook Is. Time\E|\QCoordinated Universal
> Time\E|\QCOT\E|\QCST\E|\QCuba Daylight Time\E|\QCuba Standard
> Time\E|\QCVT\E|\QCWST\E|\QCXT\E|\QDavis
> Time\E|\QDAVT\E|\QDDUT\E|\QDumont-d'Urville Time\E|\QEASST\E|\QEAST\E|\QEast
> Indonesia Time\E|\QEaster Is. Summer Time\E|\QEaster Is. Time\E|\QEastern
> African Time\E|\QEastern Daylight Time\E|\QEastern European Summer
> Time\E|\QEastern European Time\E|\QEastern Greenland Summer Time\E|\QEastern
> Greenland Time\E|\QEastern Standard Time\E|\QEastern Standard Time (New South
> Wales)\E|\QEastern Standard Time (Queensland)\E|\QEastern Standard Time
> (Tasmania)\E|\QEastern Standard Time (Victoria)\E|\QEastern Summer Time (New
> South Wales)\E|\QEastern Summer Time (Tasmania)\E|\QEastern Summer Time
> (Victoria)\E|\QEAT\E|\QECT\E|\QEcuador
> Time\E|\QEDT\E|\QEEST\E|\QEET\E|\QEGST\E|\QEGT\E|\QEST\E|\QFalkland Is.
> Time\E|\QFernando de Noronha Time\E|\QFET\E|\QFiji Summer Time\E|\QFiji
> Time\E|\QFJST\E|\QFJT\E|\QFKT\E|\QFNT\E|\QFrench Guiana Time\E|\QFrench
> Southern & Antarctic Lands Time\E|\QFurther-eastern European
> Time\E|\QGalapagos Time\E|\QGALT\E|\QGambier Time\E|\QGAMT\E|\QGeorgia
> Time\E|\QGET\E|\QGFT\E|\QGhana Mean Time\E|\QGilbert Is.
> Time\E|\QGILT\E|\QGMT\E|\QGreenwich Mean Time\E|\QGST\E|\QGulf Standard
> Time\E|\QGuyana Time\E|\QGYT\E|\QHADT\E|\QHAST\E|\QHawaii Standard
> Time\E|\QHawaii-Aleutian Daylight Time\E|\QHawaii-Aleutian Standard
> Time\E|\QHKT\E|\QHong Kong Time\E|\QHovd
> Time\E|\QHOVT\E|\QHST\E|\QICT\E|\QIDT\E|\QIndia Standard Time\E|\QIndian
> Ocean Territory Time\E|\QIndochina Time\E|\QIOT\E|\QIran Daylight
> Time\E|\QIran Standard Time\E|\QIRDT\E|\QIrish Summer
> Time\E|\QIRKT\E|\QIrkutsk Time\E|\QIRST\E|\QIsrael Daylight Time\E|\QIsrael
> Standard Time\E|\QIST\E|\QJapan Standard Time\E|\QJST\E|\QKGT\E|\QKhandyga
> Time\E|\QKirgizstan Time\E|\QKorea Standard Time\E|\QKosrae
> Time\E|\QKOST\E|\QKrasnoyarsk Time\E|\QKRAT\E|\QKST\E|\QLHST\E|\QLine Is.
> Time\E|\QLINT\E|
