[jira] [Updated] (COLLECTIONS-839) migrate BulkTest to junit 5
[ https://issues.apache.org/jira/browse/COLLECTIONS-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ng Tsz Sum updated COLLECTIONS-839: --- Description: BulkTest.java is the base class of most test of the test classes. And this class extends TestCase.java To fully migrate to Junit 5, this class should not extend TestCase.java Since most of the assertXXX method in the test is using TestCase#assertEquals, directly remove the `extends TestCase` will cause tons of compile errors. So better to do it by batch # [X]Migrate all assertion api to use Junit 5 Assertions for XXXMapTest # [X]Migrate all assertion api to use Junit 5 Assertions for XXXListTest # [X]Migrate all assertion api to use Junit 5 Assertions for XXXSetTest # [X]BulkTest not extend TestCase Acceptance Criteria * no. of tests should not change was: BulkTest.java is the base class of most test of the test classes. And this class extends TestCase.java To fully migrate to Junit 5, this class should not extend TestCase.java Since most of the assertXXX method in the test is using TestCase#assertEquals, directly remove the `extends TestCase` will cause tons of compile errors. So better to do it by batch # [ ]Migrate all assertion api to use Junit 5 Assertions for XXXMapTest # [ ]Migrate all assertion api to use Junit 5 Assertions for XXXListTest # [ ]Migrate all assertion api to use Junit 5 Assertions for XXXSetTest # [ ]BulkTest not extend TestCase Acceptance Criteria * no. of tests should not change > migrate BulkTest to junit 5 > --- > > Key: COLLECTIONS-839 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-839 > Project: Commons Collections > Issue Type: Sub-task >Reporter: Ng Tsz Sum >Priority: Major > > BulkTest.java is the base class of most test of the test classes. > And this class extends TestCase.java > To fully migrate to Junit 5, this class should not extend TestCase.java > Since most of the assertXXX method in the test is using > TestCase#assertEquals, directly remove the `extends TestCase` will cause tons > of compile errors. So better to do it by batch > # [X]Migrate all assertion api to use Junit 5 Assertions for XXXMapTest > # [X]Migrate all assertion api to use Junit 5 Assertions for XXXListTest > # [X]Migrate all assertion api to use Junit 5 Assertions for XXXSetTest > # [X]BulkTest not extend TestCase > Acceptance Criteria > * no. of tests should not change -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-839) migrate BulkTest to junit 5
[ https://issues.apache.org/jira/browse/COLLECTIONS-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ng Tsz Sum updated COLLECTIONS-839: --- Description: BulkTest.java is the base class of most test of the test classes. And this class extends TestCase.java To fully migrate to Junit 5, this class should not extend TestCase.java Since most of the assertXXX method in the test is using TestCase#assertEquals, directly remove the `extends TestCase` will cause tons of compile errors. So better to do it by batch # [ ]Migrate all assertion api to use Junit 5 Assertions for XXXMapTest # [ ]Migrate all assertion api to use Junit 5 Assertions for XXXListTest # [ ]Migrate all assertion api to use Junit 5 Assertions for XXXSetTest # [ ]BulkTest not extend TestCase Acceptance Criteria * no. of tests should not change was: BulkTest.java is the base class of most test of the test classes. And this class extends TestCase.java To fully migrate to Junit 5, this class should not extend TestCase.java Since most of the assertXXX method in the test is using TestCase#assertEquals, directly remove the `extends TestCase` will cause tons of compile errors. So better to do it by batch # Migrate all assertion api to use Junit 5 Assertions for XXXMapTest # Migrate all assertion api to use Junit 5 Assertions for XXXListTest # Migrate all assertion api to use Junit 5 Assertions for XXXSetTest # BulkTest not extend TestCase Acceptance Criteria * no. of tests should not change > migrate BulkTest to junit 5 > --- > > Key: COLLECTIONS-839 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-839 > Project: Commons Collections > Issue Type: Sub-task >Reporter: Ng Tsz Sum >Priority: Major > > BulkTest.java is the base class of most test of the test classes. > And this class extends TestCase.java > To fully migrate to Junit 5, this class should not extend TestCase.java > Since most of the assertXXX method in the test is using > TestCase#assertEquals, directly remove the `extends TestCase` will cause tons > of compile errors. So better to do it by batch > # [ ]Migrate all assertion api to use Junit 5 Assertions for XXXMapTest > # [ ]Migrate all assertion api to use Junit 5 Assertions for XXXListTest > # [ ]Migrate all assertion api to use Junit 5 Assertions for XXXSetTest > # [ ]BulkTest not extend TestCase > Acceptance Criteria > * no. of tests should not change -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-839) migrate BulkTest to junit 5
[ https://issues.apache.org/jira/browse/COLLECTIONS-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ng Tsz Sum updated COLLECTIONS-839: --- Description: BulkTest.java is the base class of most test of the test classes. And this class extends TestCase.java To fully migrate to Junit 5, this class should not extend TestCase.java Since most of the assertXXX method in the test is using TestCase#assertEquals, directly remove the `extends TestCase` will cause tons of compile errors. So better to do it by batch # Migrate all assertion api to use Junit 5 Assertions for XXXMapTest # Migrate all assertion api to use Junit 5 Assertions for XXXListTest # Migrate all assertion api to use Junit 5 Assertions for XXXSetTest # BulkTest not extend TestCase Acceptance Criteria * no. of tests should not change was: BulkTest.java is the base class of most test of the test classes. And this class extends TestCase.java To fully migrate to Junit 5, this class should not extend TestCase.java Since most of the assertXXX method in the test is using TestCase#assertEquals, directly remove the `extends TestCase` will cause tons of compile errors. So better to do it by batch > migrate BulkTest to junit 5 > --- > > Key: COLLECTIONS-839 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-839 > Project: Commons Collections > Issue Type: Sub-task >Reporter: Ng Tsz Sum >Priority: Major > > BulkTest.java is the base class of most test of the test classes. > And this class extends TestCase.java > To fully migrate to Junit 5, this class should not extend TestCase.java > Since most of the assertXXX method in the test is using > TestCase#assertEquals, directly remove the `extends TestCase` will cause tons > of compile errors. So better to do it by batch > # Migrate all assertion api to use Junit 5 Assertions for XXXMapTest > # Migrate all assertion api to use Junit 5 Assertions for XXXListTest > # Migrate all assertion api to use Junit 5 Assertions for XXXSetTest > # BulkTest not extend TestCase > Acceptance Criteria > * no. of tests should not change -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (COLLECTIONS-839) migrate BulkTest to junit 5
Ng Tsz Sum created COLLECTIONS-839: -- Summary: migrate BulkTest to junit 5 Key: COLLECTIONS-839 URL: https://issues.apache.org/jira/browse/COLLECTIONS-839 Project: Commons Collections Issue Type: Sub-task Reporter: Ng Tsz Sum BulkTest.java is the base class of most test of the test classes. And this class extends TestCase.java To fully migrate to Junit 5, this class should not extend TestCase.java Since most of the assertXXX method in the test is using TestCase#assertEquals, directly remove the `extends TestCase` will cause tons of compile errors. So better to do it by batch -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COLLECTIONS-805) Refactor usage of @Rule SetDefaultLocaleTestRule
[
https://issues.apache.org/jira/browse/COLLECTIONS-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701862#comment-17701862
]
Ng Tsz Sum commented on COLLECTIONS-805:
This is done already, can not find any SetDefaultLocaleTestRule in
1efeb335291a8994e669ba9ddd5699661d20379d
> Refactor usage of @Rule SetDefaultLocaleTestRule
>
>
> Key: COLLECTIONS-805
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-805
> Project: Commons Collections
> Issue Type: Sub-task
>Reporter: John Patrick
>Priority: Major
>
> {code:java}
> @Rule
> public final SetDefaultLocaleTestRule rule;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (LANG-1693) "CalendarUtilsTest" fails, or not...
[
https://issues.apache.org/jira/browse/LANG-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17644357#comment-17644357
]
Ng Tsz Sum edited comment on LANG-1693 at 12/7/22 2:36 PM:
---
By searching *TimeZone.setDefault* some class like
*DurationFormatUtilsTest:113* and
-*CalendarUtilsTest:38*- does not reset to original timezone.
Probably this is the cause test failed in some specific time (date of month is
different after changing the timezone)
The fix is to follow *DateUtilsTest* to reset it after test finished
was (Author: samabcde):
By searching *TimeZone.setDefault* some class like
*DurationFormatUtilsTest:113* and
*CalendarUtilsTest:38* does not reset to original timezone.
Probably this is the cause test failed in some specific time (date of month is
different after changing the timezone)
The fix is to follow *DateUtilsTest* to reset it after test finished
> "CalendarUtilsTest" fails, or not...
>
>
> Key: LANG-1693
> URL: https://issues.apache.org/jira/browse/LANG-1693
> Project: Commons Lang
> Issue Type: Test
> Components: lang.time.*
>Affects Versions: 3.12.0
>Reporter: Gilles Sadowski
>Priority: Minor
> Attachments: OUT
>
>
> Following up a [post on the ML|https://markmail.org/message/qatstzelumanopaj].
> Running
> {noformat}
> $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 mvn test
> [... skipped ...]
> [ERROR] Failures:
> [ERROR] CalendarUtilsTest.testGetDayOfMonth:32 expected: <7> but was: <6>
> [ERROR] CalendarUtilsTest.testGetDayOfYear:37 expected: <341> but was: <340>
> [INFO]
> [ERROR] Tests run: 7330, Failures: 2, Errors: 0, Skipped: 7
> [...]
> {noformat}
> Full console output attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1693) "CalendarUtilsTest" fails, or not...
[
https://issues.apache.org/jira/browse/LANG-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17644368#comment-17644368
]
Ng Tsz Sum commented on LANG-1693:
--
Sorry, *CalendarUtilsTest:38* is not related
> "CalendarUtilsTest" fails, or not...
>
>
> Key: LANG-1693
> URL: https://issues.apache.org/jira/browse/LANG-1693
> Project: Commons Lang
> Issue Type: Test
> Components: lang.time.*
>Affects Versions: 3.12.0
>Reporter: Gilles Sadowski
>Priority: Minor
> Attachments: OUT
>
>
> Following up a [post on the ML|https://markmail.org/message/qatstzelumanopaj].
> Running
> {noformat}
> $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 mvn test
> [... skipped ...]
> [ERROR] Failures:
> [ERROR] CalendarUtilsTest.testGetDayOfMonth:32 expected: <7> but was: <6>
> [ERROR] CalendarUtilsTest.testGetDayOfYear:37 expected: <341> but was: <340>
> [INFO]
> [ERROR] Tests run: 7330, Failures: 2, Errors: 0, Skipped: 7
> [...]
> {noformat}
> Full console output attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1693) "CalendarUtilsTest" fails, or not...
[
https://issues.apache.org/jira/browse/LANG-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17644357#comment-17644357
]
Ng Tsz Sum commented on LANG-1693:
--
By searching *TimeZone.setDefault* some class like
*DurationFormatUtilsTest:113* and
*CalendarUtilsTest:38* does not reset to original timezone.
Probably this is the cause test failed in some specific time (date of month is
different after changing the timezone)
The fix is to follow *DateUtilsTest* to reset it after test finished
> "CalendarUtilsTest" fails, or not...
>
>
> Key: LANG-1693
> URL: https://issues.apache.org/jira/browse/LANG-1693
> Project: Commons Lang
> Issue Type: Test
> Components: lang.time.*
>Affects Versions: 3.12.0
>Reporter: Gilles Sadowski
>Priority: Minor
> Attachments: OUT
>
>
> Following up a [post on the ML|https://markmail.org/message/qatstzelumanopaj].
> Running
> {noformat}
> $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 mvn test
> [... skipped ...]
> [ERROR] Failures:
> [ERROR] CalendarUtilsTest.testGetDayOfMonth:32 expected: <7> but was: <6>
> [ERROR] CalendarUtilsTest.testGetDayOfYear:37 expected: <341> but was: <340>
> [INFO]
> [ERROR] Tests run: 7330, Failures: 2, Errors: 0, Skipped: 7
> [...]
> {noformat}
> Full console output attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (BCEL-365) Improve Test Coverage on org.apache.bcel.generic
Ng Tsz Sum created BCEL-365: --- Summary: Improve Test Coverage on org.apache.bcel.generic Key: BCEL-365 URL: https://issues.apache.org/jira/browse/BCEL-365 Project: Commons BCEL Issue Type: Improvement Reporter: Ng Tsz Sum The coverage is low BCEL in general. https://app.codecov.io/gh/apache/commons-bcel Good start with package org.apache.bcel.generic -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COLLECTIONS-807) Upgrade org.junit.Test to org.junit.jupiter.api.Test
[
https://issues.apache.org/jira/browse/COLLECTIONS-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17564640#comment-17564640
]
Ng Tsz Sum commented on COLLECTIONS-807:
Checked out
[https://github.com/apache/commons-collections/commit/29d79003ea73528796bed63bf81b1cc508b1f215]
sang@Sams-MacBook-Pro commons-collections % grep -r "org.junit.Test" *
src/test/java/org/apache/commons/collections4/bloomfilter/AbstractHasherTest.java:import
org.junit.Test;
src/changes/changes.xml: Upgraded org.junit.Test to
org.junit.jupiter.api.Test #295, #304.
> Upgrade org.junit.Test to org.junit.jupiter.api.Test
>
>
> Key: COLLECTIONS-807
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-807
> Project: Commons Collections
> Issue Type: Sub-task
>Reporter: John Patrick
>Priority: Major
> Fix For: 4.5
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Covers '17' usages of legacy usage of;
> {code:java}
> import org.junit.Test;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (COLLECTIONS-806) Upgrade junit.framework.Test to org.junit.jupiter.api.Test
[ https://issues.apache.org/jira/browse/COLLECTIONS-806 ]
Ng Tsz Sum deleted comment on COLLECTIONS-806:
was (Author: samabcde):
Checked out
https://github.com/apache/commons-collections/commit/29d79003ea73528796bed63bf81b1cc508b1f215
sang@Sams-MacBook-Pro commons-collections % grep -r "org.junit.Test" *
src/test/java/org/apache/commons/collections4/bloomfilter/AbstractHasherTest.java:import
org.junit.Test;
src/changes/changes.xml: Upgraded org.junit.Test to
org.junit.jupiter.api.Test #295, #304.
> Upgrade junit.framework.Test to org.junit.jupiter.api.Test
> --
>
> Key: COLLECTIONS-806
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-806
> Project: Commons Collections
> Issue Type: Sub-task
>Reporter: John Patrick
>Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Covers '57' usages of legacy usage of;
> {code:java}
> import junit.framework.Test;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (COLLECTIONS-806) Upgrade junit.framework.Test to org.junit.jupiter.api.Test
[
https://issues.apache.org/jira/browse/COLLECTIONS-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17564639#comment-17564639
]
Ng Tsz Sum commented on COLLECTIONS-806:
Checked out
https://github.com/apache/commons-collections/commit/29d79003ea73528796bed63bf81b1cc508b1f215
sang@Sams-MacBook-Pro commons-collections % grep -r "org.junit.Test" *
src/test/java/org/apache/commons/collections4/bloomfilter/AbstractHasherTest.java:import
org.junit.Test;
src/changes/changes.xml: Upgraded org.junit.Test to
org.junit.jupiter.api.Test #295, #304.
> Upgrade junit.framework.Test to org.junit.jupiter.api.Test
> --
>
> Key: COLLECTIONS-806
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-806
> Project: Commons Collections
> Issue Type: Sub-task
>Reporter: John Patrick
>Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Covers '57' usages of legacy usage of;
> {code:java}
> import junit.framework.Test;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (COLLECTIONS-812) Fragile test EmptyPropertiesTest.testSave
[
https://issues.apache.org/jira/browse/COLLECTIONS-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17530395#comment-17530395
]
Ng Tsz Sum commented on COLLECTIONS-812:
The error occur when there is 1 sec different between saving expected and
actual.
!screenshot-1.png|width=728,height=306!
The string value of actual
{noformat}
#Hello world!
#Sat Apr 30 22:00:30 HKT 2022
{noformat}
The string value of expected
{noformat}
#Hello world!
#Sat Apr 30 22:00:31 HKT 2022
{noformat}
> Fragile test EmptyPropertiesTest.testSave
> -
>
> Key: COLLECTIONS-812
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-812
> Project: Commons Collections
> Issue Type: Test
>Affects Versions: 4.4
>Reporter: Bruno P. Kinoshita
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> Fragile test EmptyPropertiesTest.testSave, found in
> [https://github.com/apache/commons-collections/pull/304.]
> It passed after I kicked GH Actions.
> {noformat}
> Error: Failures:
> Error:EmptyPropertiesTest.testSave:278 #Hello world!
> #Fri Apr 29 16:05:40 GMT 2022
> ==> array contents differ at index [32], expected: <52> but was: <51>
> [INFO]
> Error: Tests run: 22274, Failures: 1, Errors: 0, Skipped: 4 {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (COLLECTIONS-812) Fragile test EmptyPropertiesTest.testSave
[
https://issues.apache.org/jira/browse/COLLECTIONS-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ng Tsz Sum updated COLLECTIONS-812:
---
Attachment: screenshot-1.png
> Fragile test EmptyPropertiesTest.testSave
> -
>
> Key: COLLECTIONS-812
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-812
> Project: Commons Collections
> Issue Type: Test
>Affects Versions: 4.4
>Reporter: Bruno P. Kinoshita
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> Fragile test EmptyPropertiesTest.testSave, found in
> [https://github.com/apache/commons-collections/pull/304.]
> It passed after I kicked GH Actions.
> {noformat}
> Error: Failures:
> Error:EmptyPropertiesTest.testSave:278 #Hello world!
> #Fri Apr 29 16:05:40 GMT 2022
> ==> array contents differ at index [32], expected: <52> but was: <51>
> [INFO]
> Error: Tests run: 22274, Failures: 1, Errors: 0, Skipped: 4 {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (COLLECTIONS-722) IteratorUtils.chainedIterator() Performance Degrades
[
https://issues.apache.org/jira/browse/COLLECTIONS-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17530087#comment-17530087
]
Ng Tsz Sum edited comment on COLLECTIONS-722 at 4/29/22 4:22 PM:
-
Possible solutions:
Since the problem is due to deeply nested IteratorChain triggering huge amount
of *hasNext()* call,
1. In IteratorChain.java, add a method *currentIteratorHasNext* method to
replace all call to *currentIterator.hasNext()* and this method will act as a
cache to reduce call to {*}currentIterator.hasNext(){*}, of course we need to
clear the cache whenever *currentIterator* next/remove is called or is pointing
to something else. Drawback is the code are less readable.
2. Update the document in *IteratorUtils.chainedIterator(iterator1, iterator2)*
to warn user not to use this method inside a for loop to chain IteratorChain.
which will create deeply nested object and result in bad performance. Suggest
them to use
*chainedIterator(final Iterator... iterators)*
or
*chainedIterator(final Collection> iterators)*
instead.
was (Author: samabcde):
Possible solutions:
1. In IteratorChain.java, add a method *currentIteratorHasNext* method to
replace all call to *currentIterator.next()* and this method will act as a
cache to reduce call to {*}currentIterator.next(){*}, of course we need to
clear the cache whenever *currentIterator* next/remove is called or is pointing
to something else. Drawback is the code are less readable.
2. Update the document in *IteratorUtils.chainedIterator(iterator1, iterator2)*
to warn user not to use this method inside a for loop to chain IteratorChain.
which will create deeply nested object and result in bad performance. Suggest
them to use
*chainedIterator(final Iterator... iterators)*
or
*chainedIterator(final Collection> iterators)*
instead.
> IteratorUtils.chainedIterator() Performance Degrades
>
>
> Key: COLLECTIONS-722
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-722
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.1
>Reporter: E P
>Priority: Major
> Attachments: IteratorUtilsTest.java
>
>
> IteratorUtils.chainedIterator() performance degrades when chaining iterators
> with chained iterators. The slowdown appears to be exponential, based upon
> the number of chains created. The attached test shows the issue.
> As a reference, the same test below works as expected using Google's Guava
> Iterator.concat() functionality. It is possible I am misusing the API, but
> the javadoc did not indicate as much.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (COLLECTIONS-722) IteratorUtils.chainedIterator() Performance Degrades
[
https://issues.apache.org/jira/browse/COLLECTIONS-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17530087#comment-17530087
]
Ng Tsz Sum commented on COLLECTIONS-722:
Possible solutions:
1. In IteratorChain.java, add a method *currentIteratorHasNext* method to
replace all call to *currentIterator.next()* and this method will act as a
cache to reduce call to {*}currentIterator.next(){*}, of course we need to
clear the cache whenever *currentIterator* next/remove is called or is pointing
to something else. Drawback is the code are less readable.
2. Update the document in *IteratorUtils.chainedIterator(iterator1, iterator2)*
to warn user not to use this method inside a for loop to chain IteratorChain.
which will create deeply nested object and result in bad performance. Suggest
them to use
*chainedIterator(final Iterator... iterators)*
or
*chainedIterator(final Collection> iterators)*
instead.
> IteratorUtils.chainedIterator() Performance Degrades
>
>
> Key: COLLECTIONS-722
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-722
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.1
>Reporter: E P
>Priority: Major
> Attachments: IteratorUtilsTest.java
>
>
> IteratorUtils.chainedIterator() performance degrades when chaining iterators
> with chained iterators. The slowdown appears to be exponential, based upon
> the number of chains created. The attached test shows the issue.
> As a reference, the same test below works as expected using Google's Guava
> Iterator.concat() functionality. It is possible I am misusing the API, but
> the javadoc did not indicate as much.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528252#comment-17528252
]
Ng Tsz Sum edited comment on COLLECTIONS-770 at 4/26/22 3:55 PM:
-
COLLECTIONS-722 This issue seems closely related
was (Author: samabcde):
This issue seems closely related
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528252#comment-17528252
]
Ng Tsz Sum commented on COLLECTIONS-770:
This issue seems closely related
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528243#comment-17528243
]
Ng Tsz Sum edited comment on COLLECTIONS-770 at 4/26/22 3:29 PM:
-
After some test, the problem is the huge number of IteratorChain#hasNext call,
but why the count growth so fast need further investigation.
Below result can be verified with attached patch [^countHasNextCall.patch]
||number||hasNext_count||
|1|3|
|2|11|
|3|30|
|4|72|
|5|161|
|6|345|
|7|720|
|8|1478|
|9|3003|
|10|6063|
|11|12194|
|12|24468|
|13|49029|
|14|98165|
|15|196452|
|16|393042|
|17|786239|
|18|1572651|
|19|3145494|
|20|6291200|
|21|12582633|
|22|25165521|
|23|50331320|
|24|100662942|
|25|201326211|
|26|402652775|
|27|805305930|
|28|1610612268|
|29|3221224973|
|30|6442450413|
was (Author: samabcde):
After some test, the problem is the huge number of IteratorChain#hasNext call,
but why the count growth so fast need to further investigate.
Below result can be verified with attached patch [^countHasNextCall.patch]
||number||hasNext_count||
|1|3|
|2|11|
|3|30|
|4|72|
|5|161|
|6|345|
|7|720|
|8|1478|
|9|3003|
|10|6063|
|11|12194|
|12|24468|
|13|49029|
|14|98165|
|15|196452|
|16|393042|
|17|786239|
|18|1572651|
|19|3145494|
|20|6291200|
|21|12582633|
|22|25165521|
|23|50331320|
|24|100662942|
|25|201326211|
|26|402652775|
|27|805305930|
|28|1610612268|
|29|3221224973|
|30|6442450413|
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528243#comment-17528243
]
Ng Tsz Sum edited comment on COLLECTIONS-770 at 4/26/22 3:29 PM:
-
After some test, the problem is the huge number of IteratorChain#hasNext call,
but why the count growth so fast need to further investigate.
Below result can be verified with attached patch [^countHasNextCall.patch]
||number||hasNext_count||
|1|3|
|2|11|
|3|30|
|4|72|
|5|161|
|6|345|
|7|720|
|8|1478|
|9|3003|
|10|6063|
|11|12194|
|12|24468|
|13|49029|
|14|98165|
|15|196452|
|16|393042|
|17|786239|
|18|1572651|
|19|3145494|
|20|6291200|
|21|12582633|
|22|25165521|
|23|50331320|
|24|100662942|
|25|201326211|
|26|402652775|
|27|805305930|
|28|1610612268|
|29|3221224973|
|30|6442450413|
was (Author: samabcde):
After some test, the problem is the huge number of IteratorChain#hasNext call,
but why the count growth so fast need to further investigate.
||number||hasNext_count||
|1|3|
|2|11|
|3|30|
|4|72|
|5|161|
|6|345|
|7|720|
|8|1478|
|9|3003|
|10|6063|
|11|12194|
|12|24468|
|13|49029|
|14|98165|
|15|196452|
|16|393042|
|17|786239|
|18|1572651|
|19|3145494|
|20|6291200|
|21|12582633|
|22|25165521|
|23|50331320|
|24|100662942|
|25|201326211|
|26|402652775|
|27|805305930|
|28|1610612268|
|29|3221224973|
|30|6442450413|
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ng Tsz Sum updated COLLECTIONS-770:
---
Attachment: countHasNextCall.patch
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528243#comment-17528243
]
Ng Tsz Sum edited comment on COLLECTIONS-770 at 4/26/22 3:27 PM:
-
After some test, the problem is the huge number of IteratorChain#hasNext call,
but why the count growth so fast need to further investigate.
||number||hasNext_count||
|1|3|
|2|11|
|3|30|
|4|72|
|5|161|
|6|345|
|7|720|
|8|1478|
|9|3003|
|10|6063|
|11|12194|
|12|24468|
|13|49029|
|14|98165|
|15|196452|
|16|393042|
|17|786239|
|18|1572651|
|19|3145494|
|20|6291200|
|21|12582633|
|22|25165521|
|23|50331320|
|24|100662942|
|25|201326211|
|26|402652775|
|27|805305930|
|28|1610612268|
|29|3221224973|
|30|6442450413|
was (Author: samabcde):
After some test, the problem is the huge number of IteratorChain#hasNext call,
but why the count growth so fast need to further investigate.
[^countHasNextCall.patch]
||number||hasNext_count||
|1|3|
|2|11|
|3|30|
|4|72|
|5|161|
|6|345|
|7|720|
|8|1478|
|9|3003|
|10|6063|
|11|12194|
|12|24468|
|13|49029|
|14|98165|
|15|196452|
|16|393042|
|17|786239|
|18|1572651|
|19|3145494|
|20|6291200|
|21|12582633|
|22|25165521|
|23|50331320|
|24|100662942|
|25|201326211|
|26|402652775|
|27|805305930|
|28|1610612268|
|29|3221224973|
|30|6442450413|
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528243#comment-17528243
]
Ng Tsz Sum commented on COLLECTIONS-770:
After some test, the problem is the huge number of IteratorChain#hasNext call,
but why the count growth so fast need to further investigate.
[^countHasNextCall.patch]
||number||hasNext_count||
|1|3|
|2|11|
|3|30|
|4|72|
|5|161|
|6|345|
|7|720|
|8|1478|
|9|3003|
|10|6063|
|11|12194|
|12|24468|
|13|49029|
|14|98165|
|15|196452|
|16|393042|
|17|786239|
|18|1572651|
|19|3145494|
|20|6291200|
|21|12582633|
|22|25165521|
|23|50331320|
|24|100662942|
|25|201326211|
|26|402652775|
|27|805305930|
|28|1610612268|
|29|3221224973|
|30|6442450413|
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, stackdump.txt
>
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (COLLECTIONS-802) ReferenceMap iterator remove violates contract
[
https://issues.apache.org/jira/browse/COLLECTIONS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17527207#comment-17527207
]
Ng Tsz Sum commented on COLLECTIONS-802:
I raised a PR https://github.com/apache/commons-collections/pull/300 to fix the
problem.
I didn't add attached ApacheMapTest as I'm not sure if we can include
*com.google.common.collect.testing* dependency in this project.
> ReferenceMap iterator remove violates contract
> --
>
> Key: COLLECTIONS-802
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-802
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Affects Versions: 4.4
>Reporter: Ben Manes
>Priority: Minor
> Attachments: ApacheMapTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Out of curiosity I ran Guava's testlib Map tests against the Apache types.
> This uncovered a contract bug where {{Iterator.remove()}} is invalidated by
> {{{}hasNext(){}}}, causing its call to no-op due to {{currentKey}} becoming
> {{{}null{}}}. The isolates case is,
> {code:java}
> @Test
> public void iterator_remove() {
> var map = new ReferenceMap<>();
> map.put(1, 2);
> var iter = map.entrySet().iterator();
> assertTrue(iter.hasNext());
> assertTrue(iter.hasNext());
> assertEquals(iter.next(), 1);
> assertFalse(iter.hasNext());
> iter.remove();
> assertEquals(map, Map.of());
> }{code}
> Guava's [testlib|https://github.com/google/guava/tree/master/guava-testlib]
> has good coverage for the Collections Framework and might be worth
> integrating. The simple test case that I wrote is attached.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (COLLECTIONS-802) ReferenceMap iterator remove violates contract
[
https://issues.apache.org/jira/browse/COLLECTIONS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17526507#comment-17526507
]
Ng Tsz Sum edited comment on COLLECTIONS-802 at 4/22/22 4:21 PM:
-
runnable with java 8, same result as stated
{code:java}
@Test
public void iterator_remove_failed_after_hasNext() {
ReferenceMap map = new ReferenceMap<>();
map.put(1, 2);
Iterator> iter = map.entrySet().iterator();
assertTrue(iter.hasNext());
assertTrue(iter.hasNext());
assertEquals(iter.next().getValue(), new Integer(2));
// comment below hasNext() call will pass
assertFalse(iter.hasNext());
iter.remove();
assertTrue("Expect empty but have entry: " + map.toString(),
map.isEmpty());
}
{code}
Suspect to be due to line 806 and 807 setting currentKey and currentValue to
null.
https://github.com/apache/commons-collections/blob/0b365e4c1833bf55648ca34b9dffd966c31cc69b/src/main/java/org/apache/commons/collections4/map/AbstractReferenceMap.java#L806
The whole hasNext method look strange as it is changing the state.
was (Author: samabcde):
runnable with java 8, same result as stated
{code:java}
@Test
public void iterator_remove_failed_after_hasNext() {
ReferenceMap map = new ReferenceMap<>();
map.put(1, 2);
Iterator> iter = map.entrySet().iterator();
assertTrue(iter.hasNext());
assertTrue(iter.hasNext());
assertEquals(iter.next().getValue(), new Integer(2));
// comment below hasNext() call will pass
assertFalse(iter.hasNext());
iter.remove();
assertTrue("Expect empty but have entry: " + map.toString(),
map.isEmpty());
}
{code}
Suspect to be due to line 806 and 807 setting currentKey and currentValue to
null.
https://github.com/apache/commons-collections/blob/0b365e4c1833bf55648ca34b9dffd966c31cc69b/src/main/java/org/apache/commons/collections4/map/AbstractReferenceMap.java#L806
> ReferenceMap iterator remove violates contract
> --
>
> Key: COLLECTIONS-802
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-802
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Affects Versions: 4.4
>Reporter: Ben Manes
>Priority: Minor
> Attachments: ApacheMapTest.java
>
>
> Out of curiosity I ran Guava's testlib Map tests against the Apache types.
> This uncovered a contract bug where {{Iterator.remove()}} is invalidated by
> {{{}hasNext(){}}}, causing its call to no-op due to {{currentKey}} becoming
> {{{}null{}}}. The isolates case is,
> {code:java}
> @Test
> public void iterator_remove() {
> var map = new ReferenceMap<>();
> map.put(1, 2);
> var iter = map.entrySet().iterator();
> assertTrue(iter.hasNext());
> assertTrue(iter.hasNext());
> assertEquals(iter.next(), 1);
> assertFalse(iter.hasNext());
> iter.remove();
> assertEquals(map, Map.of());
> }{code}
> Guava's [testlib|https://github.com/google/guava/tree/master/guava-testlib]
> has good coverage for the Collections Framework and might be worth
> integrating. The simple test case that I wrote is attached.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (COLLECTIONS-802) ReferenceMap iterator remove violates contract
[
https://issues.apache.org/jira/browse/COLLECTIONS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17526507#comment-17526507
]
Ng Tsz Sum edited comment on COLLECTIONS-802 at 4/22/22 3:58 PM:
-
runnable with java 8, same result as stated
{code:java}
@Test
public void iterator_remove_failed_after_hasNext() {
ReferenceMap map = new ReferenceMap<>();
map.put(1, 2);
Iterator> iter = map.entrySet().iterator();
assertTrue(iter.hasNext());
assertTrue(iter.hasNext());
assertEquals(iter.next().getValue(), new Integer(2));
// comment below hasNext() call will pass
assertFalse(iter.hasNext());
iter.remove();
assertTrue("Expect empty but have entry: " + map.toString(),
map.isEmpty());
}
{code}
Suspect to be due to line 806 and 807 setting currentKey and currentValue to
null.
https://github.com/apache/commons-collections/blob/0b365e4c1833bf55648ca34b9dffd966c31cc69b/src/main/java/org/apache/commons/collections4/map/AbstractReferenceMap.java#L806
was (Author: samabcde):
runnable with java 8, same result as stated
{code:java}
@Test
public void iterator_remove_failed_after_hasNext() {
ReferenceMap map = new ReferenceMap<>();
map.put(1, 2);
Iterator> iter = map.entrySet().iterator();
assertTrue(iter.hasNext());
assertTrue(iter.hasNext());
assertEquals(iter.next().getValue(), new Integer(2));
// comment below hasNext() call will pass
assertFalse(iter.hasNext());
iter.remove();
assertTrue("Expect empty but have entry: " + map.toString(),
map.isEmpty());
}
{code}
> ReferenceMap iterator remove violates contract
> --
>
> Key: COLLECTIONS-802
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-802
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Affects Versions: 4.4
>Reporter: Ben Manes
>Priority: Minor
> Attachments: ApacheMapTest.java
>
>
> Out of curiosity I ran Guava's testlib Map tests against the Apache types.
> This uncovered a contract bug where {{Iterator.remove()}} is invalidated by
> {{{}hasNext(){}}}, causing its call to no-op due to {{currentKey}} becoming
> {{{}null{}}}. The isolates case is,
> {code:java}
> @Test
> public void iterator_remove() {
> var map = new ReferenceMap<>();
> map.put(1, 2);
> var iter = map.entrySet().iterator();
> assertTrue(iter.hasNext());
> assertTrue(iter.hasNext());
> assertEquals(iter.next(), 1);
> assertFalse(iter.hasNext());
> iter.remove();
> assertEquals(map, Map.of());
> }{code}
> Guava's [testlib|https://github.com/google/guava/tree/master/guava-testlib]
> has good coverage for the Collections Framework and might be worth
> integrating. The simple test case that I wrote is attached.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (COLLECTIONS-802) ReferenceMap iterator remove violates contract
[
https://issues.apache.org/jira/browse/COLLECTIONS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17526507#comment-17526507
]
Ng Tsz Sum commented on COLLECTIONS-802:
runnable with java 8, same result as stated
{code:java}
@Test
public void iterator_remove_failed_after_hasNext() {
ReferenceMap map = new ReferenceMap<>();
map.put(1, 2);
Iterator> iter = map.entrySet().iterator();
assertTrue(iter.hasNext());
assertTrue(iter.hasNext());
assertEquals(iter.next().getValue(), new Integer(2));
// comment below hasNext() call will pass
assertFalse(iter.hasNext());
iter.remove();
assertTrue("Expect empty but have entry: " + map.toString(),
map.isEmpty());
}
{code}
> ReferenceMap iterator remove violates contract
> --
>
> Key: COLLECTIONS-802
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-802
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Affects Versions: 4.4
>Reporter: Ben Manes
>Priority: Minor
> Attachments: ApacheMapTest.java
>
>
> Out of curiosity I ran Guava's testlib Map tests against the Apache types.
> This uncovered a contract bug where {{Iterator.remove()}} is invalidated by
> {{{}hasNext(){}}}, causing its call to no-op due to {{currentKey}} becoming
> {{{}null{}}}. The isolates case is,
> {code:java}
> @Test
> public void iterator_remove() {
> var map = new ReferenceMap<>();
> map.put(1, 2);
> var iter = map.entrySet().iterator();
> assertTrue(iter.hasNext());
> assertTrue(iter.hasNext());
> assertEquals(iter.next(), 1);
> assertFalse(iter.hasNext());
> iter.remove();
> assertEquals(map, Map.of());
> }{code}
> Guava's [testlib|https://github.com/google/guava/tree/master/guava-testlib]
> has good coverage for the Collections Framework and might be worth
> integrating. The simple test case that I wrote is attached.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (BEANUTILS-540) BeanUtils.copyProperties not working in static inner class
[
https://issues.apache.org/jira/browse/BEANUTILS-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17525825#comment-17525825
]
Ng Tsz Sum commented on BEANUTILS-540:
--
The `copyProperties` will work as expected if the static inner classes are
public.
> BeanUtils.copyProperties not working in static inner class
> ---
>
> Key: BEANUTILS-540
> URL: https://issues.apache.org/jira/browse/BEANUTILS-540
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.9.3
> Environment: local test
>Reporter: Liu Jun Long
>Priority: Major
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> using below funtion copy beans, i have created two static inner class, but
> not copy successfully, then i have created two normal class, it's working
> fine.
> under Spring's package, working fine.
> package com;
> import org.apache.commons.beanutils.BeanUtils;
> //import org.springframework.beans.BeanUtils;
> public class Test {
> public static void main(String[] args) throws Exception {
> // TODO Auto-generated method stub
> Person person = new Person();
> person.setAddress("Shannxi");
> person.setName("Leo1");
> Student student = new Student();
> BeanUtils.copyProperties(student, person);
> System.out.println(student);
> //at firstly create two nomal class Employ and manager
> Employ employ = new Employ();
> employ.setAddress("Shannxi xian");
> employ.setName("Leo1");
> Manager manager = new Manager();
> BeanUtils.copyProperties(manager, employ);
> System.out.println(manager);
> }
> static class Person {
> private String name;
> private String address;
> public String getName() {
> return name;
> }
> public void setName(String name) {
> this.name = name;
> }
> public String getAddress() {
> return address;
> }
> public void setAddress(String address) {
> this.address = address;
> }
> }
> static class Student {
> private String name;
> private String address;
> public String getName() {
> return name;
> }
> public void setName(String name) {
> this.name = name;
> }
> public String getAddress() {
> return address;
> }
> public void setAddress(String address) {
> this.address = address;
> }
> @Override
> public String toString() {
> return "Student [name=" + name + ", address=" + address + "]";
> }
> }
> }
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (BEANUTILS-484) Invalid case "eId" field
[
https://issues.apache.org/jira/browse/BEANUTILS-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17525813#comment-17525813
]
Ng Tsz Sum commented on BEANUTILS-484:
--
This problem is not reproducible in
[c09e8de8|https://github.com/apache/commons-beanutils/commit/c09e8de8a0226ca288a9a7776f7d843ab610024e]
{code:java}
import java.lang.reflect.InvocationTargetException;
public class TestInvalidCase {
public String getEld() {
return eld;
}
public void setEld(String eld) {
this.eld = eld;
}
private String eld;
public static void main(String[] args) throws InvocationTargetException,
IllegalAccessException, NoSuchMethodException {
System.out.println(BeanUtils.describe(new TestInvalidCase()));
// {eld=null}
}
} {code}
> Invalid case "eId" field
>
>
> Key: BEANUTILS-484
> URL: https://issues.apache.org/jira/browse/BEANUTILS-484
> Project: Commons BeanUtils
> Issue Type: Bug
>Reporter: Daneel Yaitskov
>Priority: Major
>
> BeanUtils.describe returns "EId" for field "eId".
> I expected "eId" instead.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MATH-1617) FieldLUDecomposition with BigReal throw divide by zero error
[
https://issues.apache.org/jira/browse/MATH-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ng Tsz Sum updated MATH-1617:
-
Description:
>From
>[https://stackoverflow.com/questions/68427448/how-to-find-the-inverse-of-a-matrix-using-apache-commons-math-library-in-java/68427869?noredirect=1#comment120932354_68427869]
h3. Reproducible example
{code:java}
import org.apache.commons.math3.linear.FieldLUDecomposition;
import org.apache.commons.math3.linear.FieldMatrix;
import org.apache.commons.math3.linear.MatrixUtils;
import org.apache.commons.math3.util.BigReal;
public class REPREX {
public static void main(String[] args) {
BigReal[][] leftMatrixData = new BigReal[][]{
{new BigReal(1), new BigReal(0), new BigReal(0), new
BigReal(0)},
{new BigReal(1), new BigReal(0), new BigReal(1), new
BigReal(0)},
{new BigReal(1), new BigReal(1), new BigReal(0), new
BigReal(0)},
{new BigReal(1), new BigReal(1), new BigReal(1), new
BigReal(1)},
};
FieldMatrix leftMatrix =
MatrixUtils.createFieldMatrix(leftMatrixData);
FieldMatrix leftMatrixInverse = new
FieldLUDecomposition<>(leftMatrix)
.getSolver()
.getInverse();
// Exception in thread "main"
org.apache.commons.math3.exception.MathArithmeticException: zero not allowed
here
//at org.apache.commons.math3.util.BigReal.divide(BigReal.java:255)
//at org.apache.commons.math3.util.BigReal.divide(BigReal.java:39)
//at
org.apache.commons.math3.linear.FieldLUDecomposition.(FieldLUDecomposition.java:160)
//at stackoverflow.math.matrix.REPREX.main(REPREX.java:18)
}
}
{code}
h3. Possible reason:
In {{FieldLUDecomposition}} line 130-133
{code:java}
if (lu[nonZero][col].equals(field.getZero())) {
// try to select a better permutation choice
++nonZero;
}
{code}
Which produce incorrect result when {{lu[nonZeror][col]}} the BigDecimal val
has different scale
to {{field.getZero()}} scale. as the {{BigReal#equals}} is comparing using
{{BigDecimal#equals}}
h3. Workaround
I tried to copy class {{BigReal}} and {{BigRealField}} to {{FixBigReal}} and
{{FixBigRealField}} and replace all {{BigReal}} to {{FixBigReal}} inside. Then
override {{FixBIgReal#equals}} and {{FixBIgReal#hashcode }}as
{code:java}
@Override
public boolean equals(Object other) {
if (this == other) {
return true;
}
if (other instanceof FixBigReal) {
return d.compareTo(((FixBigReal) other).d) == 0;
}
return false;
}
...
@Override
public int hashCode() {
return Double.hashCode(d.doubleValue());
}
{code}
Then the below program will not throw error
{code:java}
import org.apache.commons.math3.linear.FieldLUDecomposition;
import org.apache.commons.math3.linear.FieldMatrix;
import org.apache.commons.math3.linear.MatrixUtils;
import org.apache.commons.math3.util.BigReal;
public class MVE {
public static void main(String[] args) {
FixBigReal[][] leftMatrixData = new FixBigReal[][]{
{new FixBigReal(1), new FixBigReal(0), new FixBigReal(0), new
FixBigReal(0)},
{new FixBigReal(1), new FixBigReal(0), new FixBigReal(1), new
FixBigReal(0)},
{new FixBigReal(1), new FixBigReal(1), new FixBigReal(0), new
FixBigReal(0)},
{new FixBigReal(1), new FixBigReal(1), new FixBigReal(1), new
FixBigReal(1)},
};
FieldMatrix leftMatrix =
MatrixUtils.createFieldMatrix(leftMatrixData);
FieldMatrix leftMatrixInverse = new
FieldLUDecomposition<>(leftMatrix)
.getSolver()
.getInverse();
}
}
{code}
was:
>From
>[https://stackoverflow.com/questions/68427448/how-to-find-the-inverse-of-a-matrix-using-apache-commons-math-library-in-java/68427869?noredirect=1#comment120932354_68427869]
h3. Reproducible example
{code:java}
import org.apache.commons.math3.linear.FieldLUDecomposition;
import org.apache.commons.math3.linear.FieldMatrix;
import org.apache.commons.math3.linear.MatrixUtils;
import org.apache.commons.math3.util.BigReal;
public class REPREX {
public static void main(String[] args) {
BigReal[][] leftMatrixData = new BigReal[][]{
{new BigReal(1), new BigReal(0), new BigReal(0), new
BigReal(0)},
{new BigReal(1), new BigReal(0), new BigReal(1), new
BigReal(0)},
{new BigReal(1), new BigReal(1), new BigReal(0), new
BigReal(0)},
{new BigReal(1), new BigReal(1), new BigReal(1), new
BigReal(1)},
};
FieldMatrix leftMatrix =
MatrixUtils.createFieldMatrix(leftMatrixData);
FieldMatrix leftMatrixInverse = new
FieldLUDecomposition<>(leftMatrix)
.getSolver()
.getInverse();
// Exc
[jira] [Commented] (MATH-1617) FieldLUDecomposition with BigReal throw divide by zero error
[
https://issues.apache.org/jira/browse/MATH-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17383370#comment-17383370
]
Ng Tsz Sum commented on MATH-1617:
--
Just created PR
https://github.com/apache/commons-math/pull/192
> FieldLUDecomposition with BigReal throw divide by zero error
>
>
> Key: MATH-1617
> URL: https://issues.apache.org/jira/browse/MATH-1617
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Ng Tsz Sum
>Priority: Major
> Fix For: 4.0
>
> Attachments: MATH-1617.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> From
> [https://stackoverflow.com/questions/68427448/how-to-find-the-inverse-of-a-matrix-using-apache-commons-math-library-in-java/68427869?noredirect=1#comment120932354_68427869]
> h3. Reproducible example
> {code:java}
> import org.apache.commons.math3.linear.FieldLUDecomposition;
> import org.apache.commons.math3.linear.FieldMatrix;
> import org.apache.commons.math3.linear.MatrixUtils;
> import org.apache.commons.math3.util.BigReal;
> public class REPREX {
> public static void main(String[] args) {
> BigReal[][] leftMatrixData = new BigReal[][]{
> {new BigReal(1), new BigReal(0), new BigReal(0), new
> BigReal(0)},
> {new BigReal(1), new BigReal(0), new BigReal(1), new
> BigReal(0)},
> {new BigReal(1), new BigReal(1), new BigReal(0), new
> BigReal(0)},
> {new BigReal(1), new BigReal(1), new BigReal(1), new
> BigReal(1)},
> };
> FieldMatrix leftMatrix =
> MatrixUtils.createFieldMatrix(leftMatrixData);
> FieldMatrix leftMatrixInverse = new
> FieldLUDecomposition<>(leftMatrix)
> .getSolver()
> .getInverse();
> // Exception in thread "main"
> org.apache.commons.math3.exception.MathArithmeticException: zero not allowed
> here
> // at org.apache.commons.math3.util.BigReal.divide(BigReal.java:255)
> // at org.apache.commons.math3.util.BigReal.divide(BigReal.java:39)
> // at
> org.apache.commons.math3.linear.FieldLUDecomposition.(FieldLUDecomposition.java:160)
> // at stackoverflow.math.matrix.REPREX.main(REPREX.java:18)
> }
> }
> {code}
> h3. Possible reason:
> In {{FieldLUDecomposition}} line 130-133
> {code:java}
> if (lu[nonZero][col].equals(field.getZero())) {
> // try to select a better permutation choice
> ++nonZero;
> }
> {code}
> Which produce incorrect result when {{lu[nonZeror][col]}} the BigDecimal val
> has different scale
> to {{field.getZero()}} scale. as the {{BigReal#equals}} is comparing using
> {{BigDecimal#equals}}
> h3. Workaround
> I tried to copy class {{BigReal}} and {{BigRealField}} to {{FixBigReal}} and
> {{FixBigRealField}} and replace all {{BigReal}} to {{FixBigReal}} inside.
> Then override {{FixBIgReal#equals}} as
> {code:java}
> @Override
> public boolean equals(Object other) {
> if (this == other) {
> return true;
> }
> if (other instanceof FixBigReal) {
> return d.compareTo(((FixBigReal) other).d) == 0;
> }
> return false;
> }
> {code}
> Then the below program will not throw error
> {code:java}
> import org.apache.commons.math3.linear.FieldLUDecomposition;
> import org.apache.commons.math3.linear.FieldMatrix;
> import org.apache.commons.math3.linear.MatrixUtils;
> import org.apache.commons.math3.util.BigReal;
> public class MVE {
> public static void main(String[] args) {
> FixBigReal[][] leftMatrixData = new FixBigReal[][]{
> {new FixBigReal(1), new FixBigReal(0), new FixBigReal(0), new
> FixBigReal(0)},
> {new FixBigReal(1), new FixBigReal(0), new FixBigReal(1), new
> FixBigReal(0)},
> {new FixBigReal(1), new FixBigReal(1), new FixBigReal(0), new
> FixBigReal(0)},
> {new FixBigReal(1), new FixBigReal(1), new FixBigReal(1), new
> FixBigReal(1)},
> };
> FieldMatrix leftMatrix =
> MatrixUtils.createFieldMatrix(leftMatrixData);
> FieldMatrix leftMatrixInverse = new
> FieldLUDecomposition<>(leftMatrix)
> .getSolver()
> .getInverse();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MATH-1617) FieldLUDecomposition with BigReal throw divide by zero error
[
https://issues.apache.org/jira/browse/MATH-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17383349#comment-17383349
]
Ng Tsz Sum commented on MATH-1617:
--
[~erans], just revisited my fix, it seems to have some problem as
{{BigReal#equals}} method is not consistent with {{hashCode}}. I am thinking to
change {{hashCode}} method of {{BigReal}} to make both consistent referring to
https://github.com/google/auto/issues/411
> FieldLUDecomposition with BigReal throw divide by zero error
>
>
> Key: MATH-1617
> URL: https://issues.apache.org/jira/browse/MATH-1617
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Ng Tsz Sum
>Priority: Major
> Fix For: 4.0
>
> Attachments: MATH-1617.patch
>
>
> From
> [https://stackoverflow.com/questions/68427448/how-to-find-the-inverse-of-a-matrix-using-apache-commons-math-library-in-java/68427869?noredirect=1#comment120932354_68427869]
> h3. Reproducible example
> {code:java}
> import org.apache.commons.math3.linear.FieldLUDecomposition;
> import org.apache.commons.math3.linear.FieldMatrix;
> import org.apache.commons.math3.linear.MatrixUtils;
> import org.apache.commons.math3.util.BigReal;
> public class REPREX {
> public static void main(String[] args) {
> BigReal[][] leftMatrixData = new BigReal[][]{
> {new BigReal(1), new BigReal(0), new BigReal(0), new
> BigReal(0)},
> {new BigReal(1), new BigReal(0), new BigReal(1), new
> BigReal(0)},
> {new BigReal(1), new BigReal(1), new BigReal(0), new
> BigReal(0)},
> {new BigReal(1), new BigReal(1), new BigReal(1), new
> BigReal(1)},
> };
> FieldMatrix leftMatrix =
> MatrixUtils.createFieldMatrix(leftMatrixData);
> FieldMatrix leftMatrixInverse = new
> FieldLUDecomposition<>(leftMatrix)
> .getSolver()
> .getInverse();
> // Exception in thread "main"
> org.apache.commons.math3.exception.MathArithmeticException: zero not allowed
> here
> // at org.apache.commons.math3.util.BigReal.divide(BigReal.java:255)
> // at org.apache.commons.math3.util.BigReal.divide(BigReal.java:39)
> // at
> org.apache.commons.math3.linear.FieldLUDecomposition.(FieldLUDecomposition.java:160)
> // at stackoverflow.math.matrix.REPREX.main(REPREX.java:18)
> }
> }
> {code}
> h3. Possible reason:
> In {{FieldLUDecomposition}} line 130-133
> {code:java}
> if (lu[nonZero][col].equals(field.getZero())) {
> // try to select a better permutation choice
> ++nonZero;
> }
> {code}
> Which produce incorrect result when {{lu[nonZeror][col]}} the BigDecimal val
> has different scale
> to {{field.getZero()}} scale. as the {{BigReal#equals}} is comparing using
> {{BigDecimal#equals}}
> h3. Workaround
> I tried to copy class {{BigReal}} and {{BigRealField}} to {{FixBigReal}} and
> {{FixBigRealField}} and replace all {{BigReal}} to {{FixBigReal}} inside.
> Then override {{FixBIgReal#equals}} as
> {code:java}
> @Override
> public boolean equals(Object other) {
> if (this == other) {
> return true;
> }
> if (other instanceof FixBigReal) {
> return d.compareTo(((FixBigReal) other).d) == 0;
> }
> return false;
> }
> {code}
> Then the below program will not throw error
> {code:java}
> import org.apache.commons.math3.linear.FieldLUDecomposition;
> import org.apache.commons.math3.linear.FieldMatrix;
> import org.apache.commons.math3.linear.MatrixUtils;
> import org.apache.commons.math3.util.BigReal;
> public class MVE {
> public static void main(String[] args) {
> FixBigReal[][] leftMatrixData = new FixBigReal[][]{
> {new FixBigReal(1), new FixBigReal(0), new FixBigReal(0), new
> FixBigReal(0)},
> {new FixBigReal(1), new FixBigReal(0), new FixBigReal(1), new
> FixBigReal(0)},
> {new FixBigReal(1), new FixBigReal(1), new FixBigReal(0), new
> FixBigReal(0)},
> {new FixBigReal(1), new FixBigReal(1), new FixBigReal(1), new
> FixBigReal(1)},
> };
> FieldMatrix leftMatrix =
> MatrixUtils.createFieldMatrix(leftMatrixData);
> FieldMatrix leftMatrixInverse = new
> FieldLUDecomposition<>(leftMatrix)
> .getSolver()
> .getInverse();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MATH-1617) FieldLUDecomposition with BigReal throw divide by zero error
[
https://issues.apache.org/jira/browse/MATH-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17382849#comment-17382849
]
Ng Tsz Sum commented on MATH-1617:
--
[~erans] , I tried to push a new branch for PR but found I have no access:
{quote}ERROR: Permission to apache/commons-math.git denied to samabcde.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
{quote}
So I attached the patch instead.
> FieldLUDecomposition with BigReal throw divide by zero error
>
>
> Key: MATH-1617
> URL: https://issues.apache.org/jira/browse/MATH-1617
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Ng Tsz Sum
>Priority: Major
> Attachments: MATH-1617.patch
>
>
> From
> [https://stackoverflow.com/questions/68427448/how-to-find-the-inverse-of-a-matrix-using-apache-commons-math-library-in-java/68427869?noredirect=1#comment120932354_68427869]
> h3. Reproducible example
> {code:java}
> import org.apache.commons.math3.linear.FieldLUDecomposition;
> import org.apache.commons.math3.linear.FieldMatrix;
> import org.apache.commons.math3.linear.MatrixUtils;
> import org.apache.commons.math3.util.BigReal;
> public class REPREX {
> public static void main(String[] args) {
> BigReal[][] leftMatrixData = new BigReal[][]{
> {new BigReal(1), new BigReal(0), new BigReal(0), new
> BigReal(0)},
> {new BigReal(1), new BigReal(0), new BigReal(1), new
> BigReal(0)},
> {new BigReal(1), new BigReal(1), new BigReal(0), new
> BigReal(0)},
> {new BigReal(1), new BigReal(1), new BigReal(1), new
> BigReal(1)},
> };
> FieldMatrix leftMatrix =
> MatrixUtils.createFieldMatrix(leftMatrixData);
> FieldMatrix leftMatrixInverse = new
> FieldLUDecomposition<>(leftMatrix)
> .getSolver()
> .getInverse();
> // Exception in thread "main"
> org.apache.commons.math3.exception.MathArithmeticException: zero not allowed
> here
> // at org.apache.commons.math3.util.BigReal.divide(BigReal.java:255)
> // at org.apache.commons.math3.util.BigReal.divide(BigReal.java:39)
> // at
> org.apache.commons.math3.linear.FieldLUDecomposition.(FieldLUDecomposition.java:160)
> // at stackoverflow.math.matrix.REPREX.main(REPREX.java:18)
> }
> }
> {code}
> h3. Possible reason:
> In {{FieldLUDecomposition}} line 130-133
> {code:java}
> if (lu[nonZero][col].equals(field.getZero())) {
> // try to select a better permutation choice
> ++nonZero;
> }
> {code}
> Which produce incorrect result when {{lu[nonZeror][col]}} the BigDecimal val
> has different scale
> to {{field.getZero()}} scale. as the {{BigReal#equals}} is comparing using
> {{BigDecimal#equals}}
> h3. Workaround
> I tried to copy class {{BigReal}} and {{BigRealField}} to {{FixBigReal}} and
> {{FixBigRealField}} and replace all {{BigReal}} to {{FixBigReal}} inside.
> Then override {{FixBIgReal#equals}} as
> {code:java}
> @Override
> public boolean equals(Object other) {
> if (this == other) {
> return true;
> }
> if (other instanceof FixBigReal) {
> return d.compareTo(((FixBigReal) other).d) == 0;
> }
> return false;
> }
> {code}
> Then the below program will not throw error
> {code:java}
> import org.apache.commons.math3.linear.FieldLUDecomposition;
> import org.apache.commons.math3.linear.FieldMatrix;
> import org.apache.commons.math3.linear.MatrixUtils;
> import org.apache.commons.math3.util.BigReal;
> public class MVE {
> public static void main(String[] args) {
> FixBigReal[][] leftMatrixData = new FixBigReal[][]{
> {new FixBigReal(1), new FixBigReal(0), new FixBigReal(0), new
> FixBigReal(0)},
> {new FixBigReal(1), new FixBigReal(0), new FixBigReal(1), new
> FixBigReal(0)},
> {new FixBigReal(1), new FixBigReal(1), new FixBigReal(0), new
> FixBigReal(0)},
> {new FixBigReal(1), new FixBigReal(1), new FixBigReal(1), new
> FixBigReal(1)},
> };
> FieldMatrix leftMatrix =
> MatrixUtils.createFieldMatrix(leftMatrixData);
> FieldMatrix leftMatrixInverse = new
> FieldLUDecomposition<>(leftMatrix)
> .getSolver()
> .getInverse();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MATH-1617) FieldLUDecomposition with BigReal throw divide by zero error
[
https://issues.apache.org/jira/browse/MATH-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ng Tsz Sum updated MATH-1617:
-
Attachment: MATH-1617.patch
> FieldLUDecomposition with BigReal throw divide by zero error
>
>
> Key: MATH-1617
> URL: https://issues.apache.org/jira/browse/MATH-1617
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Ng Tsz Sum
>Priority: Major
> Attachments: MATH-1617.patch
>
>
> From
> [https://stackoverflow.com/questions/68427448/how-to-find-the-inverse-of-a-matrix-using-apache-commons-math-library-in-java/68427869?noredirect=1#comment120932354_68427869]
> h3. Reproducible example
> {code:java}
> import org.apache.commons.math3.linear.FieldLUDecomposition;
> import org.apache.commons.math3.linear.FieldMatrix;
> import org.apache.commons.math3.linear.MatrixUtils;
> import org.apache.commons.math3.util.BigReal;
> public class REPREX {
> public static void main(String[] args) {
> BigReal[][] leftMatrixData = new BigReal[][]{
> {new BigReal(1), new BigReal(0), new BigReal(0), new
> BigReal(0)},
> {new BigReal(1), new BigReal(0), new BigReal(1), new
> BigReal(0)},
> {new BigReal(1), new BigReal(1), new BigReal(0), new
> BigReal(0)},
> {new BigReal(1), new BigReal(1), new BigReal(1), new
> BigReal(1)},
> };
> FieldMatrix leftMatrix =
> MatrixUtils.createFieldMatrix(leftMatrixData);
> FieldMatrix leftMatrixInverse = new
> FieldLUDecomposition<>(leftMatrix)
> .getSolver()
> .getInverse();
> // Exception in thread "main"
> org.apache.commons.math3.exception.MathArithmeticException: zero not allowed
> here
> // at org.apache.commons.math3.util.BigReal.divide(BigReal.java:255)
> // at org.apache.commons.math3.util.BigReal.divide(BigReal.java:39)
> // at
> org.apache.commons.math3.linear.FieldLUDecomposition.(FieldLUDecomposition.java:160)
> // at stackoverflow.math.matrix.REPREX.main(REPREX.java:18)
> }
> }
> {code}
> h3. Possible reason:
> In {{FieldLUDecomposition}} line 130-133
> {code:java}
> if (lu[nonZero][col].equals(field.getZero())) {
> // try to select a better permutation choice
> ++nonZero;
> }
> {code}
> Which produce incorrect result when {{lu[nonZeror][col]}} the BigDecimal val
> has different scale
> to {{field.getZero()}} scale. as the {{BigReal#equals}} is comparing using
> {{BigDecimal#equals}}
> h3. Workaround
> I tried to copy class {{BigReal}} and {{BigRealField}} to {{FixBigReal}} and
> {{FixBigRealField}} and replace all {{BigReal}} to {{FixBigReal}} inside.
> Then override {{FixBIgReal#equals}} as
> {code:java}
> @Override
> public boolean equals(Object other) {
> if (this == other) {
> return true;
> }
> if (other instanceof FixBigReal) {
> return d.compareTo(((FixBigReal) other).d) == 0;
> }
> return false;
> }
> {code}
> Then the below program will not throw error
> {code:java}
> import org.apache.commons.math3.linear.FieldLUDecomposition;
> import org.apache.commons.math3.linear.FieldMatrix;
> import org.apache.commons.math3.linear.MatrixUtils;
> import org.apache.commons.math3.util.BigReal;
> public class MVE {
> public static void main(String[] args) {
> FixBigReal[][] leftMatrixData = new FixBigReal[][]{
> {new FixBigReal(1), new FixBigReal(0), new FixBigReal(0), new
> FixBigReal(0)},
> {new FixBigReal(1), new FixBigReal(0), new FixBigReal(1), new
> FixBigReal(0)},
> {new FixBigReal(1), new FixBigReal(1), new FixBigReal(0), new
> FixBigReal(0)},
> {new FixBigReal(1), new FixBigReal(1), new FixBigReal(1), new
> FixBigReal(1)},
> };
> FieldMatrix leftMatrix =
> MatrixUtils.createFieldMatrix(leftMatrixData);
> FieldMatrix leftMatrixInverse = new
> FieldLUDecomposition<>(leftMatrix)
> .getSolver()
> .getInverse();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MATH-1617) FieldLUDecomposition with BigReal throw divide by zero error
Ng Tsz Sum created MATH-1617:
Summary: FieldLUDecomposition with BigReal throw divide by zero
error
Key: MATH-1617
URL: https://issues.apache.org/jira/browse/MATH-1617
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.6.1
Reporter: Ng Tsz Sum
>From
>[https://stackoverflow.com/questions/68427448/how-to-find-the-inverse-of-a-matrix-using-apache-commons-math-library-in-java/68427869?noredirect=1#comment120932354_68427869]
h3. Reproducible example
{code:java}
import org.apache.commons.math3.linear.FieldLUDecomposition;
import org.apache.commons.math3.linear.FieldMatrix;
import org.apache.commons.math3.linear.MatrixUtils;
import org.apache.commons.math3.util.BigReal;
public class REPREX {
public static void main(String[] args) {
BigReal[][] leftMatrixData = new BigReal[][]{
{new BigReal(1), new BigReal(0), new BigReal(0), new
BigReal(0)},
{new BigReal(1), new BigReal(0), new BigReal(1), new
BigReal(0)},
{new BigReal(1), new BigReal(1), new BigReal(0), new
BigReal(0)},
{new BigReal(1), new BigReal(1), new BigReal(1), new
BigReal(1)},
};
FieldMatrix leftMatrix =
MatrixUtils.createFieldMatrix(leftMatrixData);
FieldMatrix leftMatrixInverse = new
FieldLUDecomposition<>(leftMatrix)
.getSolver()
.getInverse();
// Exception in thread "main"
org.apache.commons.math3.exception.MathArithmeticException: zero not allowed
here
//at org.apache.commons.math3.util.BigReal.divide(BigReal.java:255)
//at org.apache.commons.math3.util.BigReal.divide(BigReal.java:39)
//at
org.apache.commons.math3.linear.FieldLUDecomposition.(FieldLUDecomposition.java:160)
//at stackoverflow.math.matrix.REPREX.main(REPREX.java:18)
}
}
{code}
h3. Possible reason:
In {{FieldLUDecomposition}} line 130-133
{code:java}
if (lu[nonZero][col].equals(field.getZero())) {
// try to select a better permutation choice
++nonZero;
}
{code}
Which produce incorrect result when {{lu[nonZeror][col]}} the BigDecimal val
has different scale
to {{field.getZero()}} scale. as the {{BigReal#equals}} is comparing using
{{BigDecimal#equals}}
h3. Workaround
I tried to copy class {{BigReal}} and {{BigRealField}} to {{FixBigReal}} and
{{FixBigRealField}} and replace all {{BigReal}} to {{FixBigReal}} inside. Then
override {{FixBIgReal#equals}} as
{code:java}
@Override
public boolean equals(Object other) {
if (this == other) {
return true;
}
if (other instanceof FixBigReal) {
return d.compareTo(((FixBigReal) other).d) == 0;
}
return false;
}
{code}
Then the below program will not throw error
{code:java}
import org.apache.commons.math3.linear.FieldLUDecomposition;
import org.apache.commons.math3.linear.FieldMatrix;
import org.apache.commons.math3.linear.MatrixUtils;
import org.apache.commons.math3.util.BigReal;
public class MVE {
public static void main(String[] args) {
FixBigReal[][] leftMatrixData = new FixBigReal[][]{
{new FixBigReal(1), new FixBigReal(0), new FixBigReal(0), new
FixBigReal(0)},
{new FixBigReal(1), new FixBigReal(0), new FixBigReal(1), new
FixBigReal(0)},
{new FixBigReal(1), new FixBigReal(1), new FixBigReal(0), new
FixBigReal(0)},
{new FixBigReal(1), new FixBigReal(1), new FixBigReal(1), new
FixBigReal(1)},
};
FieldMatrix leftMatrix =
MatrixUtils.createFieldMatrix(leftMatrixData);
FieldMatrix leftMatrixInverse = new
FieldLUDecomposition<>(leftMatrix)
.getSolver()
.getInverse();
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
