[jira] [Updated] (COMPRESS-462) ArArchiveInputStream allows reading without opening an entry
[
https://issues.apache.org/jira/browse/COMPRESS-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-462:
Description: The other {{ArchiveInputStream}} s either throw an exception
or return -1 when you try to read from the stream without ever calling
{{getNextEntry}}. (was: The other {{ArchiveInputStream}}s either throw an
exception or return -1 when you try to read from the stream without ever
calling {{getNextEntry}}.)
> ArArchiveInputStream allows reading without opening an entry
>
>
> Key: COMPRESS-462
> URL: https://issues.apache.org/jira/browse/COMPRESS-462
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.17
>Reporter: Stefan Bodewig
>Priority: Major
> Fix For: 1.18
>
>
> The other {{ArchiveInputStream}} s either throw an exception or return -1
> when you try to read from the stream without ever calling {{getNextEntry}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (COMPRESS-462) ArArchiveInputStream allows reading without opening an entry
[
https://issues.apache.org/jira/browse/COMPRESS-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-462.
-
Resolution: Fixed
Assignee: (was: Stefan Bodewig)
> ArArchiveInputStream allows reading without opening an entry
>
>
> Key: COMPRESS-462
> URL: https://issues.apache.org/jira/browse/COMPRESS-462
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.17
>Reporter: Stefan Bodewig
>Priority: Major
> Fix For: 1.18
>
>
> The other {{ArchiveInputStream}}s either throw an exception or return -1 when
> you try to read from the stream without ever calling {{getNextEntry}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DBCP-513) Hundreads of threads in Wait state with below stack trace
[ https://issues.apache.org/jira/browse/DBCP-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575491#comment-16575491 ] Phil Steitz commented on DBCP-513: -- It's hard to tell from the code above, but the most likely scenario is that you are failing to close the connections and the pool is simply exhausted. Threads will pile up waiting if there are no connections left in the pool. You need to make sure that your code is closing connections on all execution paths. > Hundreads of threads in Wait state with below stack trace > - > > Key: DBCP-513 > URL: https://issues.apache.org/jira/browse/DBCP-513 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.1.1 > Environment: Java Version: > 1.8.0_121 > OS Complete Version: > Linux sdpvvrwm556 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Dec 28 14:23:39 EST > 2017 x86_64 x86_64 x86_64 GNU/Linux > > DBCP Jar: > commons-dbcp2-2.1.1.jar >Reporter: Mahesh >Priority: Blocker > Attachments: Screen Shot 2018-08-05 at 10.29.52 AM.png, dbcpthread.zip > > > Hello Team, > Our application suddenly stops responding, when we checked thread dump, most > of the threads are in wait state with below stack trace, we had to restart > server to make it active, can you pelase provide your inputs on the root > cause & resolution? > > "JSockConn Thread #4532" #40906 prio=5 os_prio=0 tid=0x7f84382ce800 > nid=0xc692 waiting on condition [0x7f83d38f8000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0005c30a11b8> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:583) > at > org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:442) > at > org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363) > at > org.apache.commons.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:134) > at > org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1533) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DBCP-513) Hundreads of threads in Wait state with below stack trace
[ https://issues.apache.org/jira/browse/DBCP-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575443#comment-16575443 ] Mahesh commented on DBCP-513: - Hello Gary/Harshit, Default Max Connection Pool Size is set to 8 in Apache Connection Pool (BasicDataSource), we need to overwrite this with respect to our need, else we may see similar behavior when connections are exhausted. basicDataSource.setMaxTotal(20); Thanks, Mahesh > Hundreads of threads in Wait state with below stack trace > - > > Key: DBCP-513 > URL: https://issues.apache.org/jira/browse/DBCP-513 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.1.1 > Environment: Java Version: > 1.8.0_121 > OS Complete Version: > Linux sdpvvrwm556 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Dec 28 14:23:39 EST > 2017 x86_64 x86_64 x86_64 GNU/Linux > > DBCP Jar: > commons-dbcp2-2.1.1.jar >Reporter: Mahesh >Priority: Blocker > Attachments: Screen Shot 2018-08-05 at 10.29.52 AM.png, dbcpthread.zip > > > Hello Team, > Our application suddenly stops responding, when we checked thread dump, most > of the threads are in wait state with below stack trace, we had to restart > server to make it active, can you pelase provide your inputs on the root > cause & resolution? > > "JSockConn Thread #4532" #40906 prio=5 os_prio=0 tid=0x7f84382ce800 > nid=0xc692 waiting on condition [0x7f83d38f8000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0005c30a11b8> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:583) > at > org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:442) > at > org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363) > at > org.apache.commons.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:134) > at > org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1533) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (LANG-1409) Crashes when testing StringUtils and CharSequenceUtils
Mozhan Soltani created LANG-1409:
Summary: Crashes when testing StringUtils and CharSequenceUtils
Key: LANG-1409
URL: https://issues.apache.org/jira/browse/LANG-1409
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.7
Environment: Ubuntu 16.04.4 LTS, and McOs High Sierra-10.13.5
Junit-4.12
Reporter: Mozhan Soltani
Attachments: CharSequenceUtilsTests.java, StringUtilsTests.java
The attached test suites for {{org.apache.commons.lang3.StringUtils.java}} and
{{org.apache.commons.lang3.CharSequenceUtils.java}} come from a prototype I
have been working on which combines static analysis and automated test
generation.
The prototype analyses a specified dependency of a project to identify risky
API calls which may potentially lead to runtime exceptions. Runtime exceptions
may occur either because
# an API lacks sufficient documentation,or
# usage of the API does not conform to the specification, or
# API wrapper does not indicate the API specification as part of its own
specification.
The prototype then automatically generates test cases which show how such
exceptions may be triggered.
*Observation:*
For {{commons-lang}}, {{JDK APIs}} were analyzed. It seems that the failing
methods do not handle the potential runtime exceptions which may or may not
have been declared/documented for the JDK APIs they invoke.
*Possible fixes:*
# The failing methods under test could add internal checks on the values they
forward to the {{JDK APIs}}.
# The failing methods could handle the exceptions by adding relevant try/catch
blocks.
# The failing methods under test could specify the potential exceptions by
adding {{@throws}} in their documentation/method signatures.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1402) ArrayUtils should have null and index-safe get methods.
[
https://issues.apache.org/jira/browse/LANG-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575323#comment-16575323
]
ASF GitHub Bot commented on LANG-1402:
--
Github user asfgit closed the pull request at:
https://github.com/apache/commons-lang/pull/336
> ArrayUtils should have null and index-safe get methods.
> ---
>
> Key: LANG-1402
> URL: https://issues.apache.org/jira/browse/LANG-1402
> Project: Commons Lang
> Issue Type: New Feature
> Components: General
>Reporter: Mark Dacek
>Priority: Minor
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> There should be a safe way to retrieve a value from array without having to
> check for null and length. It would be a very simple implementation but could
> save developers a great deal of time in writing and testing.
>
> Something like
>
> {code:java}
> String[] a = null;
> ArrayUtils.get(a, 5); //returns null
> a = new String[5];
> ArrayUtils.get(a, 10); // returns null
>
> a[0] = "Hello World";
> ArrayUtils.get(a, 0); // returns "Hello World"
> {code}
>
> We could handle a few other cases - a default return value. The
> tricky/annoying thing is the need to cast everything in order to make this
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang pull request #336: LANG-1402: Null/index safe get methods for A...
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/336 ---
[jira] [Resolved] (COMPRESS-463) ZipArchiveInputStream should throw if stored entry ends prematurely
[ https://issues.apache.org/jira/browse/COMPRESS-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-463. - Resolution: Fixed Assignee: (was: Stefan Bodewig) > ZipArchiveInputStream should throw if stored entry ends prematurely > --- > > Key: COMPRESS-463 > URL: https://issues.apache.org/jira/browse/COMPRESS-463 > Project: Commons Compress > Issue Type: Bug >Affects Versions: 1.17 >Reporter: Stefan Bodewig >Priority: Major > Fix For: 1.18 > > > If the archive stream ends before the claimed size of a stored entry has been > hit the stream returns -1 rather than throwing a "truncated archive" > exception like it would do for deflated entries. > Because of this it is impossible to detect a truncated stored entry. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (COMPRESS-463) ZipArchiveInputStream should throw if stored entry ends prematurely
[ https://issues.apache.org/jira/browse/COMPRESS-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-463: Issue Type: Bug (was: Test) > ZipArchiveInputStream should throw if stored entry ends prematurely > --- > > Key: COMPRESS-463 > URL: https://issues.apache.org/jira/browse/COMPRESS-463 > Project: Commons Compress > Issue Type: Bug >Affects Versions: 1.17 >Reporter: Stefan Bodewig >Assignee: Stefan Bodewig >Priority: Major > Fix For: 1.18 > > > If the archive stream ends before the claimed size of a stored entry has been > hit the stream returns -1 rather than throwing a "truncated archive" > exception like it would do for deflated entries. > Because of this it is impossible to detect a truncated stored entry. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (COMPRESS-462) ArArchiveInputStream allows reading without opening an entry
[
https://issues.apache.org/jira/browse/COMPRESS-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-462:
Issue Type: Bug (was: Test)
> ArArchiveInputStream allows reading without opening an entry
>
>
> Key: COMPRESS-462
> URL: https://issues.apache.org/jira/browse/COMPRESS-462
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.17
>Reporter: Stefan Bodewig
>Assignee: Stefan Bodewig
>Priority: Major
> Fix For: 1.18
>
>
> The other {{ArchiveInputStream}}s either throw an exception or return -1 when
> you try to read from the stream without ever calling {{getNextEntry}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (COMPRESS-463) ZipArchiveInputStream should throw if stored entry ends prematurely
Stefan Bodewig created COMPRESS-463: --- Summary: ZipArchiveInputStream should throw if stored entry ends prematurely Key: COMPRESS-463 URL: https://issues.apache.org/jira/browse/COMPRESS-463 Project: Commons Compress Issue Type: Test Affects Versions: 1.17 Reporter: Stefan Bodewig Assignee: Stefan Bodewig Fix For: 1.18 If the archive stream ends before the claimed size of a stored entry has been hit the stream returns -1 rather than throwing a "truncated archive" exception like it would do for deflated entries. Because of this it is impossible to detect a truncated stored entry. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COMPRESS-462) ArArchiveInputStream allows reading without opening an entry
Stefan Bodewig created COMPRESS-462:
---
Summary: ArArchiveInputStream allows reading without opening an
entry
Key: COMPRESS-462
URL: https://issues.apache.org/jira/browse/COMPRESS-462
Project: Commons Compress
Issue Type: Test
Affects Versions: 1.17
Reporter: Stefan Bodewig
Assignee: Stefan Bodewig
Fix For: 1.18
The other {{ArchiveInputStream}}s either throw an exception or return -1 when
you try to read from the stream without ever calling {{getNextEntry}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JXPATH-193) methods inaccessible on java.math.BigDecimal
Beirtí Ó'Nunáin created JXPATH-193:
--
Summary: methods inaccessible on java.math.BigDecimal
Key: JXPATH-193
URL: https://issues.apache.org/jira/browse/JXPATH-193
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.3
Reporter: Beirtí Ó'Nunáin
BigDecimals can be accessed and returned as objects, but trying to access
'doubleValue' on a BigDecimal returns null. It seems the same is true for
methods on java primitive wrappers.
e.g.
{{JXPathContext.newContext(java.math.BigDecimal.ONE).getValue("doubleValue");}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VALIDATOR-444) LongValidator: numbers bigger than the maxvalue are Valid
[
https://issues.apache.org/jira/browse/VALIDATOR-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Scholz updated VALIDATOR-444:
Description:
If you try to validate a Value bigger than 9,223,372,036,854,775,807 it keeps
valid.
for example with:
{code:java}
LongValidator longValidator = new LongValidator ( true,
AbstractNumberValidator.STANDARD_FORMAT );
longValidator.isValid("9223372036854775808") // is true should be false max
long is 9223372036854775807
{code}
even worse is that:
{code:java}
longValidator.validate ( "9")
{code}
will give you the long maxValue as Result.
The IntegerValidator will give you null and nonValid.
was:
If you try to validate a Value bigger than 9,223,372,036,854,775,807 it keeps
valid.
for example with:
{code:java}
LongValidator longValidator = new LongValidator ( true,
AbstractNumberValidator.STANDARD_FORMAT );
longValidator.isValid("9223372036854775808") // is true should be false max
long is 9223372036854775807
{code}
even worse is that:
{code:java}
longValidator.getInstance ().validate ( "9")
{code}
will give you the long maxValue as Result.
The IntegerValidator will give you null and nonValid.
> LongValidator: numbers bigger than the maxvalue are Valid
> -
>
> Key: VALIDATOR-444
> URL: https://issues.apache.org/jira/browse/VALIDATOR-444
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Martin Scholz
>Priority: Major
>
> If you try to validate a Value bigger than 9,223,372,036,854,775,807 it keeps
> valid.
> for example with:
> {code:java}
> LongValidator longValidator = new LongValidator ( true,
> AbstractNumberValidator.STANDARD_FORMAT );
> longValidator.isValid("9223372036854775808") // is true should be false max
> long is 9223372036854775807
> {code}
> even worse is that:
>
> {code:java}
> longValidator.validate ( "9")
> {code}
> will give you the long maxValue as Result.
> The IntegerValidator will give you null and nonValid.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JEXL-266) Allow to remove an element from iterator collection within for-loops
Dmitri Blinov created JEXL-266:
--
Summary: Allow to remove an element from iterator collection
within for-loops
Key: JEXL-266
URL: https://issues.apache.org/jira/browse/JEXL-266
Project: Commons JEXL
Issue Type: New Feature
Affects Versions: 3.1
Environment: I have created a patch as initial implementation for this
new feature, please see github pull request here
[pr#5|https://github.com/apache/commons-jexl/pull/5]. I whould be very grateful
if this could be interesting for the community and included in master branch.
Thanks in advance!
Reporter: Dmitri Blinov
The for-loop in JEXL provides a convenient way to iterate over different types
of collections, however, its not possible for a script writer to utilize
underlying
{code:java}
iterator.remove(){code}
method within such a loop. The proposal is to introduce new {{remove}}
statement which should be used within for-loops and should internally call
{{iterator.remove()}} method and skip the loop to the next element;
For example, the following code should remove items {{1,2,3}} from set and
return value {{3}}.
{code:java}
var set = {1,2,3,4,5,6}; for (var item : set) if (item <= 3) remove; return
size(set)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (VALIDATOR-444) LongValidator: numbers bigger than the maxvalue are Valid
Martin Scholz created VALIDATOR-444:
---
Summary: LongValidator: numbers bigger than the maxvalue are Valid
Key: VALIDATOR-444
URL: https://issues.apache.org/jira/browse/VALIDATOR-444
Project: Commons Validator
Issue Type: Bug
Components: Routines
Affects Versions: 1.6
Reporter: Martin Scholz
If you try to validate a Value bigger than 9,223,372,036,854,775,807 it keeps
valid.
for example with:
{code:java}
LongValidator longValidator = new LongValidator ( true,
AbstractNumberValidator.STANDARD_FORMAT );
longValidator.isValid("9223372036854775808") // is true should be false max
long is 9223372036854775807
{code}
even worse is that:
{code:java}
longValidator.getInstance ().validate ( "9")
{code}
will give you the long maxValue as Result.
The IntegerValidator will give you null and nonValid.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1406) StringIndexOutOfBoundsException in StringUtils.replaceIgnoreCase
[
https://issues.apache.org/jira/browse/LANG-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574494#comment-16574494
]
ASF GitHub Bot commented on LANG-1406:
--
Github user kinow commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/340#discussion_r208851249
--- Diff: src/main/java/org/apache/commons/lang3/StringUtils.java ---
@@ -5596,8 +5596,8 @@ private static String replace(final String text,
String searchString, final Stri
}
String searchText = text;
if (ignoreCase) {
- searchText = text.toLowerCase();
- searchString = searchString.toLowerCase();
+ searchText = text.toUpperCase();
+ searchString = searchString.toUpperCase();
--- End diff --
Just leaving a comment here too to have a review here in GitHub. While your
example works, as the character is considered already in upper case, the
reverse case would still fail after changing from `toLowerCase` to
`toUpperCase`. So I think we should find another solution or update the
documentation stating how the code works with unicode.
> StringIndexOutOfBoundsException in StringUtils.replaceIgnoreCase
>
>
> Key: LANG-1406
> URL: https://issues.apache.org/jira/browse/LANG-1406
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Michael Ryan
>Priority: Major
>
> STEPS TO REPRODUCE:
> {code}
> StringUtils.replaceIgnoreCase("\u0130x", "x", "")
> {code}
> EXPECTED: "\u0130" is returned.
> ACTUAL: StringIndexOutOfBoundsException
> This happens because the replace method is assuming that text.length() ==
> text.toLowerCase().length(), which is not true for certain characters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang pull request #340: [LANG-1406] StringIndexOutOfBoundsException ...
Github user kinow commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/340#discussion_r208851249
--- Diff: src/main/java/org/apache/commons/lang3/StringUtils.java ---
@@ -5596,8 +5596,8 @@ private static String replace(final String text,
String searchString, final Stri
}
String searchText = text;
if (ignoreCase) {
- searchText = text.toLowerCase();
- searchString = searchString.toLowerCase();
+ searchText = text.toUpperCase();
+ searchString = searchString.toUpperCase();
--- End diff --
Just leaving a comment here too to have a review here in GitHub. While your
example works, as the character is considered already in upper case, the
reverse case would still fail after changing from `toLowerCase` to
`toUpperCase`. So I think we should find another solution or update the
documentation stating how the code works with unicode.
---
[GitHub] commons-lang issue #340: [LANG-1406] StringIndexOutOfBoundsException in Stri...
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/340 Oh, that does make sense now. So the first visible character we see is the ["Latin Capital Letter I with Dot Above"](https://unicode-table.com/en/#0130) (see also [this other link](https://en.wikipedia.org/wiki/Dotted_and_dotless_I)), and the second an `x`. And doing `toUpperCase()` simply won't change it as it's considered already upper case. When doing a `toLowerCase`, it gets translated into two visible characters. The second is the normal `x`. While the first contains two codepoints. I tested in Python, and got the lower case `i` (`print(u"\u0069")`) followed by a character invisible by itself (`print (u"\u0307")`). The special/invisible character, is visible when coming after certain letters. ```python >>> print(u"\u0307") >>> print(u"\u0069\u0307") iÌ >>> print(u"\u0068\u0307") hÌ >>> print(u"\u0067\u0307") gÌ >>> print(u"\u0067\u0307") ``` When we get these invisible characters, as we have one code point more, the length returned is not 2, but 3. Resulting in exception in this issue. I don't believe the fix here would fix the reverse case, where we had a lower case, single codepoint, unicode; that would be represented by a two code codepoint. The exception could happen again (I haven't investigated whether such case exist, but I'm assuming there could be such case - if not now, maybe a character could still be added in future editions). What do you think @HiuKwok ? Any suggestions? I'm not sure if there's any easy way to fix this case, except by adding a note to the documentation saying that the method is not intended to be used with unicode strings, as it doesn't handle supplementary characters well. Or maybe we could try to remove the `length()` call around the `StringBuilder`'s near the end of the method... ---
[jira] [Commented] (LANG-1406) StringIndexOutOfBoundsException in StringUtils.replaceIgnoreCase
[
https://issues.apache.org/jira/browse/LANG-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574490#comment-16574490
]
ASF GitHub Bot commented on LANG-1406:
--
Github user kinow commented on the issue:
https://github.com/apache/commons-lang/pull/340
Oh, that does make sense now. So the first visible character we see is the
["Latin Capital Letter I with Dot Above"](https://unicode-table.com/en/#0130)
(see also [this other
link](https://en.wikipedia.org/wiki/Dotted_and_dotless_I)), and the second an
`x`. And doing `toUpperCase()` simply won't change it as it's considered
already upper case.
When doing a `toLowerCase`, it gets translated into two visible characters.
The second is the normal `x`. While the first contains two codepoints. I tested
in Python, and got the lower case `i` (`print(u"\u0069")`) followed by a
character invisible by itself (`print (u"\u0307")`).
The special/invisible character, is visible when coming after certain
letters.
```python
>>> print(u"\u0307")
>>> print(u"\u0069\u0307")
i̇
>>> print(u"\u0068\u0307")
ḣ
>>> print(u"\u0067\u0307")
ġ
>>> print(u"\u0067\u0307")
```
When we get these invisible characters, as we have one code point more, the
length returned is not 2, but 3. Resulting in exception in this issue.
I don't believe the fix here would fix the reverse case, where we had a
lower case, single codepoint, unicode; that would be represented by a two code
codepoint. The exception could happen again (I haven't investigated whether
such case exist, but I'm assuming there could be such case - if not now, maybe
a character could still be added in future editions).
What do you think @HiuKwok ? Any suggestions? I'm not sure if there's any
easy way to fix this case, except by adding a note to the documentation saying
that the method is not intended to be used with unicode strings, as it doesn't
handle supplementary characters well. Or maybe we could try to remove the
`length()` call around the `StringBuilder`'s near the end of the method...
> StringIndexOutOfBoundsException in StringUtils.replaceIgnoreCase
>
>
> Key: LANG-1406
> URL: https://issues.apache.org/jira/browse/LANG-1406
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Michael Ryan
>Priority: Major
>
> STEPS TO REPRODUCE:
> {code}
> StringUtils.replaceIgnoreCase("\u0130x", "x", "")
> {code}
> EXPECTED: "\u0130" is returned.
> ACTUAL: StringIndexOutOfBoundsException
> This happens because the replace method is assuming that text.length() ==
> text.toLowerCase().length(), which is not true for certain characters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
