[jira] [Created] (COMPRESS-589) 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while 1.20 not
chen created COMPRESS-589:
-
Summary: 1.21 throws a 'java.io.IOException: Truncated TAR
archive' exception while 1.20 not
Key: COMPRESS-589
URL: https://issues.apache.org/jira/browse/COMPRESS-589
Project: Commons Compress
Issue Type: Bug
Affects Versions: 1.21
Reporter: chen
the bug happens when I use the TarArchiveInputStream to read bytes from the
current tar archive entry.
the trace shows as below
{code:java}
08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated TAR
archive08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException:
Truncated TAR archive08-27 14:39:18.657 10633 10963 W System.err: at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
08-27 14:39:18.657 10633 10963 W System.err: at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
08-27 14:39:18.657 10633 10963 W System.err: at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
{code}
but when i downgrade to 1.20, the exception will not show again, so I think it
is a bug in the new version
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-589) 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while 1.20 not
[
https://issues.apache.org/jira/browse/COMPRESS-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chen updated COMPRESS-589:
--
Description:
the bug happens when I use the TarArchiveInputStream to read bytes from the
current tar archive entry.
the trace shows as below
{code:java}
08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated TAR
archive
08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated TAR
archive
08-27 14:39:18.657 10633 10963 W System.err: at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
08-27 14:39:18.657 10633 10963 W System.err: at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
08-27 14:39:18.657 10633 10963 W System.err: at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
{code}
but when i downgrade to 1.20, the exception will not show again, so I think it
is a bug in the new version
was:
the bug happens when I use the TarArchiveInputStream to read bytes from the
current tar archive entry.
the trace shows as below
{code:java}
08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated TAR
archive08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException:
Truncated TAR archive08-27 14:39:18.657 10633 10963 W System.err: at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
08-27 14:39:18.657 10633 10963 W System.err: at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
08-27 14:39:18.657 10633 10963 W System.err: at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
{code}
but when i downgrade to 1.20, the exception will not show again, so I think it
is a bug in the new version
> 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while
> 1.20 not
> ---
>
> Key: COMPRESS-589
> URL: https://issues.apache.org/jira/browse/COMPRESS-589
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: chen
>Priority: Major
>
> the bug happens when I use the TarArchiveInputStream to read bytes from the
> current tar archive entry.
> the trace shows as below
> {code:java}
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
> {code}
> but when i downgrade to 1.20, the exception will not show again, so I think
> it is a bug in the new version
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-589) 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while 1.20 not
[
https://issues.apache.org/jira/browse/COMPRESS-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406083#comment-17406083
]
chen commented on COMPRESS-589:
---
@[~erans]
yes, the archive is created by the "Commons Compress" library and regardless of
created by 1.20 or 1.21, the archive cannot be dearchived on 1.21, but on
1.20 everything is normal
> 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while
> 1.20 not
> ---
>
> Key: COMPRESS-589
> URL: https://issues.apache.org/jira/browse/COMPRESS-589
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: chen
>Priority: Major
>
> the bug happens when I use the TarArchiveInputStream to read bytes from the
> current tar archive entry.
> the trace shows as below
> {code:java}
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
> {code}
> but when i downgrade to 1.20, the exception will not show again, so I think
> it is a bug in the new version
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-589) 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while 1.20 not
[
https://issues.apache.org/jira/browse/COMPRESS-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17414884#comment-17414884
]
chen commented on COMPRESS-589:
---
[~ggregory]
figure out that it will throw excption when the .tar file is about 2GB, and
little less than 2GB, everything OK, but little bigger than 2GB, the excption
throwed.
thats weird and maybe the file is too hard to upload
> 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while
> 1.20 not
> ---
>
> Key: COMPRESS-589
> URL: https://issues.apache.org/jira/browse/COMPRESS-589
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: chen
>Priority: Major
>
> the bug happens when I use the TarArchiveInputStream to read bytes from the
> current tar archive entry.
> the trace shows as below
> {code:java}
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
> {code}
> but when i downgrade to 1.20, the exception will not show again, so I think
> it is a bug in the new version
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-589) 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while 1.20 not
[
https://issues.apache.org/jira/browse/COMPRESS-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17419651#comment-17419651
]
chen commented on COMPRESS-589:
---
[~ggregory] [~erans]
bro, I found the easiest way to display the problem.
first of all, We ran into this issue on an Android device
{code:java}
adb shell dd if=/dev/zero of=sdcard/test/1.mp4 bs=1024 count=102400
{code}
we can use the above adb command to construct 21 files which is 100M each under
sdcard/test/.
After using compress to tar the file, it is normal with 1.20, but 'Truncated
TAR archive' occurs with 1.21 when we try to untar the file .
hope you guys can help me.
THX
> 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while
> 1.20 not
> ---
>
> Key: COMPRESS-589
> URL: https://issues.apache.org/jira/browse/COMPRESS-589
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: chen
>Priority: Major
>
> the bug happens when I use the TarArchiveInputStream to read bytes from the
> current tar archive entry.
> the trace shows as below
> {code:java}
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
> {code}
> but when i downgrade to 1.20, the exception will not show again, so I think
> it is a bug in the new version
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-589) 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while 1.20 not
[
https://issues.apache.org/jira/browse/COMPRESS-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420178#comment-17420178
]
chen commented on COMPRESS-589:
---
[~erans]
yes,the size of tar file are the same,both 2202021376 bytes
> 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while
> 1.20 not
> ---
>
> Key: COMPRESS-589
> URL: https://issues.apache.org/jira/browse/COMPRESS-589
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: chen
>Priority: Major
>
> the bug happens when I use the TarArchiveInputStream to read bytes from the
> current tar archive entry.
> the trace shows as below
> {code:java}
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
> {code}
> but when i downgrade to 1.20, the exception will not show again, so I think
> it is a bug in the new version
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-589) 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while 1.20 not
[
https://issues.apache.org/jira/browse/COMPRESS-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420227#comment-17420227
]
chen commented on COMPRESS-589:
---
[~erans]
I use 'tar cvf testcc.tar ./test/' and the size of the TAR file is 2202021888
bytes
> 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while
> 1.20 not
> ---
>
> Key: COMPRESS-589
> URL: https://issues.apache.org/jira/browse/COMPRESS-589
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: chen
>Priority: Major
>
> the bug happens when I use the TarArchiveInputStream to read bytes from the
> current tar archive entry.
> the trace shows as below
> {code:java}
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
> {code}
> but when i downgrade to 1.20, the exception will not show again, so I think
> it is a bug in the new version
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-589) 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while 1.20 not
[
https://issues.apache.org/jira/browse/COMPRESS-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420256#comment-17420256
]
chen commented on COMPRESS-589:
---
[~erans]
We ran into this issue on an *{color:#FF}Android device{color}*，when we try
to uncompress it by 1.21, the "java.io.IOException: Truncated TAR archive'
exception" occurs while 1.20 not
> 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while
> 1.20 not
> ---
>
> Key: COMPRESS-589
> URL: https://issues.apache.org/jira/browse/COMPRESS-589
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: chen
>Priority: Major
>
> the bug happens when I use the TarArchiveInputStream to read bytes from the
> current tar archive entry.
> the trace shows as below
> {code:java}
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
> {code}
> but when i downgrade to 1.20, the exception will not show again, so I think
> it is a bug in the new version
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-589) 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while 1.20 not
[
https://issues.apache.org/jira/browse/COMPRESS-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chen updated COMPRESS-589:
--
Description:
the bug happens when I use the TarArchiveInputStream to read bytes from the
current tar archive entry.
first of all, we ran into this issue on an *{color:#ff}Android
device{color}*
the trace shows as below
{code:java}
08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated TAR
archive
08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated TAR
archive
08-27 14:39:18.657 10633 10963 W System.err: at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
08-27 14:39:18.657 10633 10963 W System.err: at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
08-27 14:39:18.657 10633 10963 W System.err: at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
{code}
but when i downgrade to 1.20, the exception will not show again, so I think it
is a bug in the new version
was:
the bug happens when I use the TarArchiveInputStream to read bytes from the
current tar archive entry.
the trace shows as below
{code:java}
08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated TAR
archive
08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated TAR
archive
08-27 14:39:18.657 10633 10963 W System.err: at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
08-27 14:39:18.657 10633 10963 W System.err: at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
08-27 14:39:18.657 10633 10963 W System.err: at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
{code}
but when i downgrade to 1.20, the exception will not show again, so I think it
is a bug in the new version
> 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while
> 1.20 not
> ---
>
> Key: COMPRESS-589
> URL: https://issues.apache.org/jira/browse/COMPRESS-589
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: chen
>Priority: Major
>
> the bug happens when I use the TarArchiveInputStream to read bytes from the
> current tar archive entry.
> first of all, we ran into this issue on an *{color:#ff}Android
> device{color}*
> the trace shows as below
> {code:java}
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
> {code}
> but when i downgrade to 1.20, the exception will not show again, so I think
> it is a bug in the new version
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-589) 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while 1.20 not
[
https://issues.apache.org/jira/browse/COMPRESS-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420428#comment-17420428
]
chen commented on COMPRESS-589:
---
[~erans]
would you mind test the issue on an Android device , appreciate for that :D
> 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while
> 1.20 not
> ---
>
> Key: COMPRESS-589
> URL: https://issues.apache.org/jira/browse/COMPRESS-589
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: chen
>Priority: Major
>
> the bug happens when I use the TarArchiveInputStream to read bytes from the
> current tar archive entry.
> first of all, we ran into this issue on an *{color:#ff}Android
> device{color}*
> the trace shows as below
> {code:java}
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
> {code}
> but when i downgrade to 1.20, the exception will not show again, so I think
> it is a bug in the new version
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-589) 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while 1.20 not
[
https://issues.apache.org/jira/browse/COMPRESS-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17427465#comment-17427465
]
chen commented on COMPRESS-589:
---
[~erans]
On Android devices, if the tar package size is greater than 2G,
inputStream.available() in the skipRecordPadding() method will return 0
On Windows, it will return 2147483647 (Integer.MAX_VALUE)
whether it cause the issue?
> 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while
> 1.20 not
> ---
>
> Key: COMPRESS-589
> URL: https://issues.apache.org/jira/browse/COMPRESS-589
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: chen
>Priority: Major
>
> the bug happens when I use the TarArchiveInputStream to read bytes from the
> current tar archive entry.
> first of all, we ran into this issue on an *{color:#ff}Android
> device{color}*
> the trace shows as below
> {code:java}
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
> {code}
> but when i downgrade to 1.20, the exception will not show again, so I think
> it is a bug in the new version
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-589) 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while 1.20 not
[
https://issues.apache.org/jira/browse/COMPRESS-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17434652#comment-17434652
]
chen commented on COMPRESS-589:
---
[~peterlee]
that works，yyds！！
> 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while
> 1.20 not
> ---
>
> Key: COMPRESS-589
> URL: https://issues.apache.org/jira/browse/COMPRESS-589
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: chen
>Priority: Major
>
> the bug happens when I use the TarArchiveInputStream to read bytes from the
> current tar archive entry.
> first of all, we ran into this issue on an *{color:#ff}Android
> device{color}*
> the trace shows as below
> {code:java}
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
> {code}
> but when i downgrade to 1.20, the exception will not show again, so I think
> it is a bug in the new version
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-708) Create CollectionUtils.hashCode using Equator
[
https://issues.apache.org/jira/browse/COLLECTIONS-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16922219#comment-16922219
]
Chen commented on COLLECTIONS-708:
--
Hi [~ggregory]
Is that the hashcode for Collection implemented using Equator hash?
int hashCode = 1;
for (final E: collection B){
hashCode = 31 * hashCode + equator. hash (e);
}
> Create CollectionUtils.hashCode using Equator
> -
>
> Key: COLLECTIONS-708
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-708
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Affects Versions: 4.2
>Reporter: Andrei Ivanov
>Priority: Major
>
> Hello,
> After discovering {{CollectionUtils#isEqualCollection}} that uses an
> {{Equator}}, I've started to implement {{Equator}} s for my classes, only to
> discover that I can't generate hashCodes for the collections that hold these
> classes using {{Equator#hash}}.
> I hope something like {{CollectionUtils#hashCode(Collection, Equator)}} can
> be implemented.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1462) After version Commons-lang3.4 DateFormatUtils has a bug
[
https://issues.apache.org/jira/browse/LANG-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16923034#comment-16923034
]
Chen commented on LANG-1462:
The TimeZone parameter of the format method is used to create an instance of
FastDateFormat with an empty default value, so I don't think this is a BUG.
Just need to modify the method description.
> After version Commons-lang3.4 DateFormatUtils has a bug
> ---
>
> Key: LANG-1462
> URL: https://issues.apache.org/jira/browse/LANG-1462
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.5, 3.6, 3.7, 3.8, 3.9, 3.8.1
>Reporter: Lijun Liang
>Priority: Critical
>
> The code is as follows ：
> Calendar cale = Calendar.getInstance();
> System.out.println("Old time is " + DateFormatUtils.format(cale,
> "MMddHHmmss"));
> cale.setTimeZone(TimeZone.getTimeZone("JST"));
> System.out.println("New time is " + DateFormatUtils.format(cale,
> "MMddHHmmss"));
>
> The results of commons-lang3 3.4：
> Old time is 20190605144536
> New time is 20190605154536
>
> The results of the version after commons-lang3 3.4:
> Old time is 20190605144536
> New time is 20190605144536
>
> We found that the time zone setting was invalidated when it was formatted
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16923235#comment-16923235
]
Chen commented on LANG-1453:
Since case mappings are not always 1:1 char mappings, the resulting may be a
different length than the original， so String#toUpperCase & String#toLowerCase
can't be used with String#indexOf which to find position.
How to fix this problem? I think we should use regex. I will try it later.
> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
>
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16923376#comment-16923376
]
Chen commented on LANG-1453:
Add replace method in RegExUtils.java
public static String replace(final String text, final String regex, final
String replacement, int max,
final boolean ignoreCase) {
if (text == null || regex == null || replacement == null || max
== 0) {
return text;
}
Pattern pattern = ignoreCase ? Pattern.compile(regex,
Pattern.CASE_INSENSITIVE) : Pattern.compile(regex);
Matcher matcher = pattern.matcher(text);
boolean result = matcher.find();
if (!result) {
return text;
}
StringBuffer sb = new StringBuffer();
do {
matcher.appendReplacement(sb, replacement);
if (--max == 0) {
break;
}
result = matcher.find();
} while (result);
matcher.appendTail(sb);
return sb.toString();
}
Modify the replace method in StringUtils.java
private static String replace(final String text, String searchString,
final String replacement, int max, final boolean ignoreCase) {
if (isEmpty(text) || isEmpty(searchString) || replacement == null
|| max == 0) {
return text;
}
return RegExUtils.replace(text, searchString, replacement, max,
ignoreCase);
}
Let's test it together.
> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
>
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1488) Possible serialization failed
[
https://issues.apache.org/jira/browse/LANG-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16926242#comment-16926242
]
Chen commented on LANG-1488:
The Class A should implements Serializable, if Class A is a inner class, the
outer class also must implements Serializable.
> Possible serialization failed
> -
>
> Key: LANG-1488
> URL: https://issues.apache.org/jira/browse/LANG-1488
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.tuple.*
>Reporter: Silence Tai
>Priority: Major
> Fix For: 4.0
>
>
> *Pair* fails to properly constrain the generic parameters, requiring them to
> implement the *Serializable* interface, which may cause serialization to fail.
> Example:
> {code:java}
> static class A { }
> @Test
> public void testSerialization() throws Exception {
> final ImmutablePair origPair = ImmutablePair.of(new A(),
> "foo");
> final ByteArrayOutputStream baos = new ByteArrayOutputStream();
> final ObjectOutputStream out = new ObjectOutputStream(baos);
> out.writeObject(origPair);
> out.close();
> baos.close();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (COLLECTIONS-708) Create CollectionUtils.hashCode using Equator
[
https://issues.apache.org/jira/browse/COLLECTIONS-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16922219#comment-16922219
]
Chen edited comment on COLLECTIONS-708 at 9/10/19 6:21 AM:
---
Hi [~ggregory]
Is that the hashcode for Collection implemented using Equator hash?
{code:java}
int hashCode = 1;
for (final object e: collection B){
hashCode = 31 * hashCode + equator. hash (e);
}
{code}
was (Author: guoping1):
Hi [~ggregory]
Is that the hashcode for Collection implemented using Equator hash?
{code:java}
int hashCode = 1;
for (final E: collection B){
hashCode = 31 * hashCode + equator. hash (e);
}
{code}
> Create CollectionUtils.hashCode using Equator
> -
>
> Key: COLLECTIONS-708
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-708
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Affects Versions: 4.2
>Reporter: Andrei Ivanov
>Priority: Major
>
> Hello,
> After discovering {{CollectionUtils#isEqualCollection}} that uses an
> {{Equator}}, I've started to implement {{Equator}} s for my classes, only to
> discover that I can't generate hashCodes for the collections that hold these
> classes using {{Equator#hash}}.
> I hope something like {{CollectionUtils#hashCode(Collection, Equator)}} can
> be implemented.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (COLLECTIONS-708) Create CollectionUtils.hashCode using Equator
[
https://issues.apache.org/jira/browse/COLLECTIONS-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16922219#comment-16922219
]
Chen edited comment on COLLECTIONS-708 at 9/10/19 6:21 AM:
---
Hi [~ggregory]
Is that the hashcode for Collection implemented using Equator hash?
{code:java}
int hashCode = 1;
for (final E: collection B){
hashCode = 31 * hashCode + equator. hash (e);
}
{code}
was (Author: guoping1):
Hi [~ggregory]
Is that the hashcode for Collection implemented using Equator hash?
int hashCode = 1;
for (final E: collection B){
hashCode = 31 * hashCode + equator. hash (e);
}
> Create CollectionUtils.hashCode using Equator
> -
>
> Key: COLLECTIONS-708
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-708
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Affects Versions: 4.2
>Reporter: Andrei Ivanov
>Priority: Major
>
> Hello,
> After discovering {{CollectionUtils#isEqualCollection}} that uses an
> {{Equator}}, I've started to implement {{Equator}} s for my classes, only to
> discover that I can't generate hashCodes for the collections that hold these
> classes using {{Equator#hash}}.
> I hope something like {{CollectionUtils#hashCode(Collection, Equator)}} can
> be implemented.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (LANG-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16923376#comment-16923376
]
Chen edited comment on LANG-1453 at 9/10/19 6:22 AM:
-
Add replace method in RegExUtils.java
{code:java}
public static String replace(final String text, final String regex, final
String replacement, int max,
final boolean ignoreCase) {
if (text == null || regex == null || replacement == null || max
== 0) {
return text;
}
Pattern pattern = ignoreCase ? Pattern.compile(regex,
Pattern.CASE_INSENSITIVE) : Pattern.compile(regex);
Matcher matcher = pattern.matcher(text);
boolean result = matcher.find();
if (!result) {
return text;
}
StringBuffer sb = new StringBuffer();
do {
matcher.appendReplacement(sb, replacement);
if (--max == 0) {
break;
}
result = matcher.find();
} while (result);
matcher.appendTail(sb);
return sb.toString();
}
{code}
Modify the replace method in StringUtils.java
{code:java}
private static String replace(final String text, String searchString, final
String replacement, int max, final boolean ignoreCase) {
if (isEmpty(text) || isEmpty(searchString) || replacement == null
|| max == 0) {
return text;
}
return RegExUtils.replace(text, searchString, replacement, max,
ignoreCase);
}
{code}
Let's test it together.
was (Author: guoping1):
Add replace method in RegExUtils.java
public static String replace(final String text, final String regex, final
String replacement, int max,
final boolean ignoreCase) {
if (text == null || regex == null || replacement == null || max
== 0) {
return text;
}
Pattern pattern = ignoreCase ? Pattern.compile(regex,
Pattern.CASE_INSENSITIVE) : Pattern.compile(regex);
Matcher matcher = pattern.matcher(text);
boolean result = matcher.find();
if (!result) {
return text;
}
StringBuffer sb = new StringBuffer();
do {
matcher.appendReplacement(sb, replacement);
if (--max == 0) {
break;
}
result = matcher.find();
} while (result);
matcher.appendTail(sb);
return sb.toString();
}
Modify the replace method in StringUtils.java
private static String replace(final String text, String searchString,
final String replacement, int max, final boolean ignoreCase) {
if (isEmpty(text) || isEmpty(searchString) || replacement == null
|| max == 0) {
return text;
}
return RegExUtils.replace(text, searchString, replacement, max,
ignoreCase);
}
Let's test it together.
> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
>
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16927355#comment-16927355
]
Chen commented on LANG-1453:
Hi, [~ggregory]
It doesn't work either.
String#toUpperCase & String#toLowerCase are not always 1:1 char mappings, the
resulting may be a different length than the original.
> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
>
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933188#comment-16933188
]
Chen commented on COLLECTIONS-714:
--
Hi, [~rohanpadhye] [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char)
> is different from the string "x\u" (of length = 2 chars). However,
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce:
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1); // key of length 2
> map.put("x\uy", 2); // key of length 3
> Assert.assertEquals(3, map.size()); // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size()); // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and
> "x\uy". The key "x" gets overwritten. Here is another way to repro the
> bug:
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings.
> In general, I believe this also breaks the JDK Map contract since the keys
> "x".equals("x\u") is false.
> This bug was found automatically using JQF:
> [https://github.com/rohanpadhye/jqf].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933188#comment-16933188
]
Chen edited comment on COLLECTIONS-714 at 9/19/19 9:14 AM:
---
Hi, [~rohanpadhye] [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
testNullTerminatedKey2
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.selectKey("x").equals("x\u")); // fail
}
{code}
was (Author: guoping1):
Hi, [~rohanpadhye] [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char)
> is different from the string "x\u" (of length = 2 chars). However,
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce:
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1); // key of length 2
> map.put("x\uy", 2); // key of length 3
> Assert.assertEquals(3, map.size()); // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size()); // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and
> "x\uy". The key "x" gets overwritten. Here is another way to repro the
> bug:
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings.
> In general, I believe this also breaks the JDK Map contract since the keys
> "x".equals("x\u") is false.
> This bug was found automatically using JQF:
> [https://github.com/rohanpadhye/jqf].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933188#comment-16933188
]
Chen edited comment on COLLECTIONS-714 at 9/19/19 9:15 AM:
---
Hi, [~rohanpadhye] [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
testNullTerminatedKey2
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue("x\u".equals(trie.selectKey("x"))); // fail
}
{code}
was (Author: guoping1):
Hi, [~rohanpadhye] [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
testNullTerminatedKey2
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.selectKey("x").equals("x\u")); // fail
}
{code}
> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char)
> is different from the string "x\u" (of length = 2 chars). However,
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce:
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1); // key of length 2
> map.put("x\uy", 2); // key of length 3
> Assert.assertEquals(3, map.size()); // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size()); // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and
> "x\uy". The key "x" gets overwritten. Here is another way to repro the
> bug:
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings.
> In general, I believe this also breaks the JDK Map contract since the keys
> "x".equals("x\u") is false.
> This bug was found automatically using JQF:
> [https://github.com/rohanpadhye/jqf].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933188#comment-16933188
]
Chen edited comment on COLLECTIONS-714 at 9/19/19 9:16 AM:
---
Hi, [~rohanpadhye], [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
If need, i will provide a PR on github.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
testNullTerminatedKey2
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue("x\u".equals(trie.selectKey("x"))); // fail
}
{code}
was (Author: guoping1):
Hi, [~rohanpadhye] [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
testNullTerminatedKey2
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue("x\u".equals(trie.selectKey("x"))); // fail
}
{code}
> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char)
> is different from the string "x\u" (of length = 2 chars). However,
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce:
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1); // key of length 2
> map.put("x\uy", 2); // key of length 3
> Assert.assertEquals(3, map.size()); // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size()); // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and
> "x\uy". The key "x" gets overwritten. Here is another way to repro the
> bug:
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings.
> In general, I believe this also breaks the JDK Map contract since the keys
> "x".equals("x\u") is false.
> This bug was found automatically using JQF:
> [https://github.com/rohanpadhye/jqf].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933188#comment-16933188
]
Chen edited comment on COLLECTIONS-714 at 9/19/19 1:27 PM:
---
Hi, [~rohanpadhye], [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
If need, i will provide a PR on github.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
but, when run testNullTerminatedKey2, trie.containsKey("x") fail.
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.containsKey("x\u")); // ok
Assert.assertTrue(trie.containsKey("x")); // fail
}
{code}
was (Author: guoping1):
Hi, [~rohanpadhye], [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
If need, i will provide a PR on github.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
testNullTerminatedKey2
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue("x\u".equals(trie.selectKey("x"))); // fail
}
{code}
> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char)
> is different from the string "x\u" (of length = 2 chars). However,
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce:
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1); // key of length 2
> map.put("x\uy", 2); // key of length 3
> Assert.assertEquals(3, map.size()); // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size()); // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and
> "x\uy". The key "x" gets overwritten. Here is another way to repro the
> bug:
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings.
> In general, I believe this also breaks the JDK Map contract since the keys
> "x".equals("x\u") is false.
> This bug was found automatically using JQF:
> [https://github.com/rohanpadhye/jqf].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933188#comment-16933188
]
Chen edited comment on COLLECTIONS-714 at 9/19/19 1:27 PM:
---
Hi, [~rohanpadhye], [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
but, when run testNullTerminatedKey2, trie.containsKey("x") fail.
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.containsKey("x\u")); // ok
Assert.assertTrue(trie.containsKey("x")); // fail
}
{code}
was (Author: guoping1):
Hi, [~rohanpadhye], [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
If need, i will provide a PR on github.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
but, when run testNullTerminatedKey2, trie.containsKey("x") fail.
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.containsKey("x\u")); // ok
Assert.assertTrue(trie.containsKey("x")); // fail
}
{code}
> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char)
> is different from the string "x\u" (of length = 2 chars). However,
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce:
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1); // key of length 2
> map.put("x\uy", 2); // key of length 3
> Assert.assertEquals(3, map.size()); // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size()); // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and
> "x\uy". The key "x" gets overwritten. Here is another way to repro the
> bug:
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings.
> In general, I believe this also breaks the JDK Map contract since the keys
> "x".equals("x\u") is false.
> This bug was found automatically using JQF:
> [https://github.com/rohanpadhye/jqf].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16937640#comment-16937640
]
Chen commented on COLLECTIONS-714:
--
Because 0=‘\u’ we can't fix this problem, we need to add comments to
explain this situation at PatriciaTrie.
Don't support '\u' in the key.
> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char)
> is different from the string "x\u" (of length = 2 chars). However,
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce:
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1); // key of length 2
> map.put("x\uy", 2); // key of length 3
> Assert.assertEquals(3, map.size()); // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size()); // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and
> "x\uy". The key "x" gets overwritten. Here is another way to repro the
> bug:
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings.
> In general, I believe this also breaks the JDK Map contract since the keys
> "x".equals("x\u") is false.
> This bug was found automatically using JQF:
> [https://github.com/rohanpadhye/jqf].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-674) Add Collections Drain Method
[
https://issues.apache.org/jira/browse/COLLECTIONS-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938352#comment-16938352
]
Chen commented on COLLECTIONS-674:
--
{code:java}
public static Collection drain(Collection input, int start, int
count) {
if (null == input) {
throw new IllegalArgumentException("The Collection of
Input can't be null.");
}
if (start < 0) {
throw new IllegalArgumentException("The Start can't
less than 0.");
}
if (count < 1) {
throw new IllegalArgumentException("The Count can't
less than 1.");
}
if (input.size() < start + count) {
throw new IllegalArgumentException(
"The sum of start and count cann't be
greater than the size of collection.");
}
Collection result = new ArrayList(count);
Iterator iterator = input.iterator();
while (count > 0) {
result.add(iterator.next());
iterator.remove();
count = count - 1;
}
return result;
}
{code}
> Add Collections Drain Method
>
>
> Key: COLLECTIONS-674
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-674
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Affects Versions: 4.1
>Reporter: David Mollitor
>Priority: Major
>
> Add a {{Collections.drain()}} method which removes the first N elements from
> the collection and returns them. This method would have the side-effect of
> modifying the input collections (due to removal).
>
> {code:java}
> // Some suggestions
> void Collections.drain(Collection from, Collection to, int count);
> Collection Collections.drain(Collection from, int count);{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-674) Add Collections Drain Method
[
https://issues.apache.org/jira/browse/COLLECTIONS-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938352#comment-16938352
]
Chen edited comment on COLLECTIONS-674 at 9/26/19 7:06 AM:
---
{code:java}
public static Collection drain(Collection input, int start, int
count) {
if (null == input) {
throw new IllegalArgumentException("The collection
can't be null.");
}
if (start < 0) {
throw new IllegalArgumentException("The Start can't
less than 0.");
}
if (count < 1) {
throw new IllegalArgumentException("The Count can't
less than 1.");
}
if (input.size() < start + count) {
throw new IllegalArgumentException(
"The sum of start and count cann't be
greater than the size of collection.");
}
Collection result = new ArrayList(count);
Iterator iterator = input.iterator();
while (count > 0) {
result.add(iterator.next());
iterator.remove();
count = count - 1;
}
return result;
}
{code}
was (Author: guoping1):
{code:java}
public static Collection drain(Collection input, int start, int
count) {
if (null == input) {
throw new IllegalArgumentException("The Collection of
Input can't be null.");
}
if (start < 0) {
throw new IllegalArgumentException("The Start can't
less than 0.");
}
if (count < 1) {
throw new IllegalArgumentException("The Count can't
less than 1.");
}
if (input.size() < start + count) {
throw new IllegalArgumentException(
"The sum of start and count cann't be
greater than the size of collection.");
}
Collection result = new ArrayList(count);
Iterator iterator = input.iterator();
while (count > 0) {
result.add(iterator.next());
iterator.remove();
count = count - 1;
}
return result;
}
{code}
> Add Collections Drain Method
>
>
> Key: COLLECTIONS-674
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-674
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Affects Versions: 4.1
>Reporter: David Mollitor
>Priority: Major
>
> Add a {{Collections.drain()}} method which removes the first N elements from
> the collection and returns them. This method would have the side-effect of
> modifying the input collections (due to removal).
>
> {code:java}
> // Some suggestions
> void Collections.drain(Collection from, Collection to, int count);
> Collection Collections.drain(Collection from, int count);{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (COLLECTIONS-729) Add test case to IteratorUtilsTest
Chen created COLLECTIONS-729: Summary: Add test case to IteratorUtilsTest Key: COLLECTIONS-729 URL: https://issues.apache.org/jira/browse/COLLECTIONS-729 Project: Commons Collections Issue Type: Test Components: Collection Affects Versions: 4.4 Reporter: Chen Add test case to IteratorUtilsTest -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-729) Add test case to IteratorUtilsTest
[ https://issues.apache.org/jira/browse/COLLECTIONS-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chen updated COLLECTIONS-729: - External issue URL: https://github.com/apache/commons-collections/pull/84 Labels: test (was: ) add tests to IteratorUtilsTest > Add test case to IteratorUtilsTest > -- > > Key: COLLECTIONS-729 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-729 > Project: Commons Collections > Issue Type: Test > Components: Collection >Affects Versions: 4.4 >Reporter: Chen >Priority: Major > Labels: test > > Add test case to IteratorUtilsTest -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (COLLECTIONS-729) Add test case to IteratorUtilsTest
[ https://issues.apache.org/jira/browse/COLLECTIONS-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chen updated COLLECTIONS-729: - Comment: was deleted (was: add tests to IteratorUtilsTest) > Add test case to IteratorUtilsTest > -- > > Key: COLLECTIONS-729 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-729 > Project: Commons Collections > Issue Type: Test > Components: Collection >Affects Versions: 4.4 >Reporter: Chen >Priority: Major > Labels: test > > Add test case to IteratorUtilsTest -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (COLLECTIONS-729) Add test case to IteratorUtilsTest
[ https://issues.apache.org/jira/browse/COLLECTIONS-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chen updated COLLECTIONS-729: - Comment: was deleted (was: Add testcaces to IteratorUtilsTest) > Add test case to IteratorUtilsTest > -- > > Key: COLLECTIONS-729 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-729 > Project: Commons Collections > Issue Type: Test > Components: Collection >Affects Versions: 4.4 >Reporter: Chen >Priority: Major > Labels: test > > Add test case to IteratorUtilsTest -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-729) Add test case to IteratorUtilsTest
[ https://issues.apache.org/jira/browse/COLLECTIONS-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chen updated COLLECTIONS-729: - External issue URL: https://github.com/apache/commons-collections/pull/86 (was: https://github.com/apache/commons-collections/pull/84) Add testcaces to IteratorUtilsTest > Add test case to IteratorUtilsTest > -- > > Key: COLLECTIONS-729 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-729 > Project: Commons Collections > Issue Type: Test > Components: Collection >Affects Versions: 4.4 >Reporter: Chen >Priority: Major > Labels: test > > Add test case to IteratorUtilsTest -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-698) Expand LoopingListIterator
[
https://issues.apache.org/jira/browse/COLLECTIONS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16956603#comment-16956603
]
Chen commented on COLLECTIONS-698:
--
hi [~belugabehr] ,what does the parameter loops mean?
for your example
if a list has 3 items (1,2,3) then \{{LoopingListIterator(list, 1, 2)}} would
iterate: (2,3,1,2,3,1)?
> Expand LoopingListIterator
> --
>
> Key: COLLECTIONS-698
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-698
> Project: Commons Collections
> Issue Type: Improvement
> Components: Iterator
>Affects Versions: 4.2
>Reporter: David Mollitor
>Priority: Minor
>
> Please enhance {{LoopingListIterator}} to accept a starting offset and a
> number to indicate the number of loops.
> https://docs.oracle.com/javase/7/docs/api/java/util/List.html#listIterator(int)
> {code:java}
> public LoopingListIterator(List list, int offset, int loops);
> {code}
> As I imagine it, if a list has 3 items (1,2,3) then
> {{LoopingListIterator(list, 1, 1)}} would iterate: (2,3,1)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-674) Add Collections Drain Method
[
https://issues.apache.org/jira/browse/COLLECTIONS-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938352#comment-16938352
]
Chen edited comment on COLLECTIONS-674 at 10/23/19 7:29 AM:
I will push a PR for it.
was (Author: guoping1):
{code:java}
public static Collection drain(Collection input, int start, int
count) {
if (null == input) {
throw new IllegalArgumentException("The collection
can't be null.");
}
if (start < 0) {
throw new IllegalArgumentException("The Start can't
less than 0.");
}
if (count < 1) {
throw new IllegalArgumentException("The Count can't
less than 1.");
}
if (input.size() < start + count) {
throw new IllegalArgumentException(
"The sum of start and count cann't be
greater than the size of collection.");
}
Collection result = new ArrayList(count);
Iterator iterator = input.iterator();
while (count > 0) {
result.add(iterator.next());
iterator.remove();
count = count - 1;
}
return result;
}
{code}
> Add Collections Drain Method
>
>
> Key: COLLECTIONS-674
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-674
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Affects Versions: 4.1
>Reporter: David Mollitor
>Priority: Major
>
> Add a {{Collections.drain()}} method which removes the first N elements from
> the collection and returns them. This method would have the side-effect of
> modifying the input collections (due to removal).
>
> {code:java}
> // Some suggestions
> void Collections.drain(Collection from, Collection to, int count);
> Collection Collections.drain(Collection from, int count);{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-698) Expand LoopingListIterator
[
https://issues.apache.org/jira/browse/COLLECTIONS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16958460#comment-16958460
]
Chen commented on COLLECTIONS-698:
--
hi [~belugabehr] how can we define one loop？ if just readonly then that
situation is simple , but if there is add , remove ,and previous , in these
situation , I can't define when is one loop is over
> Expand LoopingListIterator
> --
>
> Key: COLLECTIONS-698
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-698
> Project: Commons Collections
> Issue Type: Improvement
> Components: Iterator
>Affects Versions: 4.2
>Reporter: David Mollitor
>Priority: Minor
>
> Please enhance {{LoopingListIterator}} to accept a starting offset and a
> number to indicate the number of loops.
> https://docs.oracle.com/javase/7/docs/api/java/util/List.html#listIterator(int)
> {code:java}
> public LoopingListIterator(List list, int offset, int loops);
> {code}
> As I imagine it, if a list has 3 items (1,2,3) then
> {{LoopingListIterator(list, 1, 1)}} would iterate: (2,3,1)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16961031#comment-16961031
]
Chen commented on COLLECTIONS-714:
--
throw IllegalArgumentException in StringKeyAnalyzer#bitIndex when we call put?
> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char)
> is different from the string "x\u" (of length = 2 chars). However,
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce:
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1); // key of length 2
> map.put("x\uy", 2); // key of length 3
> Assert.assertEquals(3, map.size()); // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size()); // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and
> "x\uy". The key "x" gets overwritten. Here is another way to repro the
> bug:
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings.
> In general, I believe this also breaks the JDK Map contract since the keys
> "x".equals("x\u") is false.
> This bug was found automatically using JQF:
> [https://github.com/rohanpadhye/jqf].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-698) Expand LoopingListIterator
[
https://issues.apache.org/jira/browse/COLLECTIONS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16961763#comment-16961763
]
Chen commented on COLLECTIONS-698:
--
[~belugabehr] in that case ,if we add loop control inside Iterator ,that is not
so beautiful .maybe we should only extend the offset of begining loop. just
like below:
{code:java}
//代码占位符
final List list = Arrays.asList("1", "2", "3","4","5");
final LoopingListIterator loop = new LoopingListIterator<>(list,2);
for (int loops = 0;loops < 3*list.size();loops++)
{ System.out.print(loop.next()+", "); }
{code}
{code:java}
//代码占位符
3, 4, 5, 1, 2, 3, 4, 5, 1, 2, 3, 4, 5, 1, 2,
{code}
> Expand LoopingListIterator
> --
>
> Key: COLLECTIONS-698
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-698
> Project: Commons Collections
> Issue Type: Improvement
> Components: Iterator
>Affects Versions: 4.2
>Reporter: David Mollitor
>Priority: Minor
>
> Please enhance {{LoopingListIterator}} to accept a starting offset and a
> number to indicate the number of loops.
> https://docs.oracle.com/javase/7/docs/api/java/util/List.html#listIterator(int)
> {code:java}
> public LoopingListIterator(List list, int offset, int loops);
> {code}
> As I imagine it, if a list has 3 items (1,2,3) then
> {{LoopingListIterator(list, 1, 1)}} would iterate: (2,3,1)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-551) Move Iterable related methods from CollectionUtils to IterableUtils
[
https://issues.apache.org/jira/browse/COLLECTIONS-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16963731#comment-16963731
]
Chen commented on COLLECTIONS-551:
--
hi [~ggregory]，I found that two pr of gonmarques in 2015 ( fix COLLECTIONS-550
and COLLECTIONS-551 ), gonmarques write the code but didn't merged . And in
2017 chtompki commentd at COLLECTIONS-551 need a rebasing onto the {{master}}
branch and opening a new pull request. but gonmarques have not time for it.
what can I do for this issue , may be a rebasing onto the {{master}} branch and
opening a new pull request for COLLECTIONS-550 and COLLECTIONS-551 ?
> Move Iterable related methods from CollectionUtils to IterableUtils
> ---
>
> Key: COLLECTIONS-551
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-551
> Project: Commons Collections
> Issue Type: Improvement
>Affects Versions: 4.0
>Reporter: Thomas Neidhart
>Priority: Major
> Fix For: 5.0, 4.5
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[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=16964728#comment-16964728
]
Chen commented on COLLECTIONS-722:
--
hi [~dragonmacher]， I think you misusing the API in testcase ,cause
IteratorUtils.chainedIterator(iterator, next) will create a new object ,so if
you create 50 times , that you will get a 50 deepth object .
below is a new test
{code:java}
//代码占位符
@Test
public void testIteratorUtils_ChainedIteartorPerformance() {
Map> source = new HashMap<>();
for (int i = 0; i < 50; i++) {
source.put(i, Arrays.asList(1, 2, 3));
}
Iterator iterator = IteratorUtils.emptyIterator();
IteratorChain iteratorChain =
(IteratorChain)IteratorUtils.chainedIterator(iterator);
Set>> entries = source.entrySet();
for (Entry> entry : entries) {
Iterator next = entry.getValue().iterator();
iteratorChain.addIterator(next);
}
while (iteratorChain.hasNext()) {
System.out.println(iteratorChain.next());
}
}
{code}
> 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.3.4#803005)
[jira] [Commented] (COLLECTIONS-564) Add support for Deque interface
[ https://issues.apache.org/jira/browse/COLLECTIONS-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16964733#comment-16964733 ] Chen commented on COLLECTIONS-564: -- Since the Decke interface has been added in Java 6, if it is necessary to add support for it in Collections? If not, can this issue be closed? > Add support for Deque interface > --- > > Key: COLLECTIONS-564 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-564 > Project: Commons Collections > Issue Type: New Feature >Reporter: Thomas Neidhart >Priority: Major > > As we moved on to Java 6, we can now also support the Deque interface. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16965269#comment-16965269
]
Chen commented on COLLECTIONS-663:
--
Hello, Gary D.Gregory
In this [PR|[https://github.com/apache/commons-collections/pull/108/files]],
the testMultiValuedMapIterator() method test MapIterator.setValue() .That
MapIterator.setValue() is really not supported。In ArrayListValuedHashMap,
HashSetValuedHashMap, TransformedMultiValuedMap and UnmodifiableMultiValuedMap
will throw UnsupportedOperationException when use MapIterator.setValue().
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without
> debugging the code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16965277#comment-16965277
]
Chen commented on COLLECTIONS-663:
--
Hi,Gary D.Gregory
See code, In the AbstractMultiValuedMap.java,
1、AbstractMultiValuedMap.MapIterator() methos will return private
MultiValuedMapIterator class
2、MultiValuedMapIterator class will call
AbstractMultiValuedMap.entries().iterator()
3、AbstractMultiValuedMap.entries() will return private EntryValues class
4、EntryValues class will return LazyIteratorChain overide nextIterator which
call MultiValuedMapEntry class
5、MultiValuedMapEntry class setValue() method throw
UnsupportedOperationException.
so MapIterator.setValue() is not support!
Ithink it is a proplem, Should we solve this problem by submitting a PR?
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without
> debugging the code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16965277#comment-16965277
]
Chen edited comment on COLLECTIONS-663 at 11/2/19 9:08 AM:
---
Hi,Gary D.Gregory
Read the code, In the AbstractMultiValuedMap.java,
1、AbstractMultiValuedMap.MapIterator() methos will return private
MultiValuedMapIterator class
2、MultiValuedMapIterator class will call
AbstractMultiValuedMap.entries().iterator()
3、AbstractMultiValuedMap.entries() will return private EntryValues class
4、EntryValues class will return LazyIteratorChain overide nextIterator which
call MultiValuedMapEntry class
5、MultiValuedMapEntry class setValue() method throw
UnsupportedOperationException.
so MapIterator.setValue() is not support!
Ithink it is a proplem, Should we solve this problem by submitting a PR?
was (Author: guoping1):
Hi,Gary D.Gregory
See code, In the AbstractMultiValuedMap.java,
1、AbstractMultiValuedMap.MapIterator() methos will return private
MultiValuedMapIterator class
2、MultiValuedMapIterator class will call
AbstractMultiValuedMap.entries().iterator()
3、AbstractMultiValuedMap.entries() will return private EntryValues class
4、EntryValues class will return LazyIteratorChain overide nextIterator which
call MultiValuedMapEntry class
5、MultiValuedMapEntry class setValue() method throw
UnsupportedOperationException.
so MapIterator.setValue() is not support!
Ithink it is a proplem, Should we solve this problem by submitting a PR?
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without
> debugging the code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16965277#comment-16965277
]
Chen edited comment on COLLECTIONS-663 at 11/4/19 2:16 AM:
---
Hi,@Gary D.Gregory
Read the code, In the AbstractMultiValuedMap.java,
1、AbstractMultiValuedMap.MapIterator() methos will return private
MultiValuedMapIterator class
2、MultiValuedMapIterator class will call
AbstractMultiValuedMap.entries().iterator()
3、AbstractMultiValuedMap.entries() will return private EntryValues class
4、EntryValues class will return LazyIteratorChain overide nextIterator which
call MultiValuedMapEntry class
5、MultiValuedMapEntry class setValue() method throw
UnsupportedOperationException.
so MapIterator.setValue() is not support!
Ithink it is a proplem, Should we solve this problem by submitting a PR?
was (Author: guoping1):
Hi,Gary D.Gregory
Read the code, In the AbstractMultiValuedMap.java,
1、AbstractMultiValuedMap.MapIterator() methos will return private
MultiValuedMapIterator class
2、MultiValuedMapIterator class will call
AbstractMultiValuedMap.entries().iterator()
3、AbstractMultiValuedMap.entries() will return private EntryValues class
4、EntryValues class will return LazyIteratorChain overide nextIterator which
call MultiValuedMapEntry class
5、MultiValuedMapEntry class setValue() method throw
UnsupportedOperationException.
so MapIterator.setValue() is not support!
Ithink it is a proplem, Should we solve this problem by submitting a PR?
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without
> debugging the code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-533) Add a MultiValuedLinkedHashMap to preserve insertion order
[ https://issues.apache.org/jira/browse/COLLECTIONS-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966366#comment-16966366 ] Chen commented on COLLECTIONS-533: -- Hi, [~dipanjan21] [~tn] Now it is version 4.3. Has this feature been developed?Now it is version 4.3. Has this feature been developed? > Add a MultiValuedLinkedHashMap to preserve insertion order > -- > > Key: COLLECTIONS-533 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-533 > Project: Commons Collections > Issue Type: New Feature > Components: Map >Reporter: Benedikt Ritter >Priority: Major > Labels: github > Fix For: 4.x > > > Placeholder ticket for https://github.com/apache/commons-collections/pull/3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16965277#comment-16965277
]
Chen edited comment on COLLECTIONS-663 at 11/4/19 2:21 AM:
---
Hi,[~ggregory]
Read the code, In the AbstractMultiValuedMap.java,
1、AbstractMultiValuedMap.MapIterator() methos will return private
MultiValuedMapIterator class
2、MultiValuedMapIterator class will call
AbstractMultiValuedMap.entries().iterator()
3、AbstractMultiValuedMap.entries() will return private EntryValues class
4、EntryValues class will return LazyIteratorChain overide nextIterator which
call MultiValuedMapEntry class
5、MultiValuedMapEntry class setValue() method throw
UnsupportedOperationException.
so MapIterator.setValue() is not support!
Ithink it is a proplem, Should we solve this problem by submitting a PR?
was (Author: guoping1):
Hi,@Gary D.Gregory
Read the code, In the AbstractMultiValuedMap.java,
1、AbstractMultiValuedMap.MapIterator() methos will return private
MultiValuedMapIterator class
2、MultiValuedMapIterator class will call
AbstractMultiValuedMap.entries().iterator()
3、AbstractMultiValuedMap.entries() will return private EntryValues class
4、EntryValues class will return LazyIteratorChain overide nextIterator which
call MultiValuedMapEntry class
5、MultiValuedMapEntry class setValue() method throw
UnsupportedOperationException.
so MapIterator.setValue() is not support!
Ithink it is a proplem, Should we solve this problem by submitting a PR?
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without
> debugging the code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16965269#comment-16965269
]
Chen edited comment on COLLECTIONS-663 at 11/4/19 2:21 AM:
---
Hello, [~ggregory]
In this [PR|[https://github.com/apache/commons-collections/pull/108/files]],
the testMultiValuedMapIterator() method test MapIterator.setValue() .That
MapIterator.setValue() is really not supported。In ArrayListValuedHashMap,
HashSetValuedHashMap, TransformedMultiValuedMap and UnmodifiableMultiValuedMap
will throw UnsupportedOperationException when use MapIterator.setValue().
was (Author: guoping1):
Hello, Gary D.Gregory
In this [PR|[https://github.com/apache/commons-collections/pull/108/files]],
the testMultiValuedMapIterator() method test MapIterator.setValue() .That
MapIterator.setValue() is really not supported。In ArrayListValuedHashMap,
HashSetValuedHashMap, TransformedMultiValuedMap and UnmodifiableMultiValuedMap
will throw UnsupportedOperationException when use MapIterator.setValue().
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without
> debugging the code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-533) Add a MultiValuedLinkedHashMap to preserve insertion order
[ https://issues.apache.org/jira/browse/COLLECTIONS-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966366#comment-16966366 ] Chen edited comment on COLLECTIONS-533 at 11/4/19 2:23 AM: --- Hi, [~dipanjan21], [~tn] Now it is version 4.3. Has this feature been developed? was (Author: guoping1): Hi, [~dipanjan21] [~tn] Now it is version 4.3. Has this feature been developed?Now it is version 4.3. Has this feature been developed? > Add a MultiValuedLinkedHashMap to preserve insertion order > -- > > Key: COLLECTIONS-533 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-533 > Project: Commons Collections > Issue Type: New Feature > Components: Map >Reporter: Benedikt Ritter >Priority: Major > Labels: github > Fix For: 4.x > > > Placeholder ticket for https://github.com/apache/commons-collections/pull/3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-486) Update/Augment Sorted(Map|Set) implementations with Navigable(Map|Set)
[ https://issues.apache.org/jira/browse/COLLECTIONS-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966378#comment-16966378 ] Chen commented on COLLECTIONS-486: -- Hi, [~tn]: Is it time to implement this ? > Update/Augment Sorted(Map|Set) implementations with Navigable(Map|Set) > -- > > Key: COLLECTIONS-486 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-486 > Project: Commons Collections > Issue Type: Improvement > Components: BidiMap, Map, Set >Affects Versions: 4.0 >Reporter: Hollis Waite >Priority: Minor > Fix For: 5.0 > > > Navigable interfaces are "intended to supersede" Sorted ones > (http://docs.oracle.com/javase/6/docs/technotes/guides/collections/changes6.html). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-520) Add a CopyOnWrite implementation of Map
[ https://issues.apache.org/jira/browse/COLLECTIONS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966381#comment-16966381 ] Chen commented on COLLECTIONS-520: -- So does this feature need to be implemented? > Add a CopyOnWrite implementation of Map > --- > > Key: COLLECTIONS-520 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-520 > Project: Commons Collections > Issue Type: New Feature > Components: Map >Affects Versions: 4.0 >Reporter: Daniel Feist >Priority: Major > Fix For: 4.x > > > Java provides implementations for List's and Set's but Map is missing. > Jersey uses an implementation > ([com.sun.jersey.client.impl.CopyOnWriteHashMap|https://java.net/projects/jersey/sources/svn/content/trunk/jersey/jersey-client/src/main/java/com/sun/jersey/client/impl/CopyOnWriteHashMap.java]) > but it doesn't fully implement Map because entrySet/keySet/values are not > mutable. > I implemented a CaseInsensitiveCopyOnWriteMap in Mule and while it serves our > purposes it's not 100% complete and isn't thread-safe, and it would be good > to see an implementation in commons. (BTW: I plan to extend from > AsbtractHashedMap once we moved to 4.0/4.1). > See: > [org.mule.util.CopyOnWriteCaseInsensitiveMap|https://github.com/mulesoft/mule/blob/716893e6231be47dccd3cfba9619762e146b4b84/core/src/main/java/org/mule/util/CopyOnWriteCaseInsensitiveMap.java] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-546) Implement expiring queue like already exist PassiveExpiringMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966423#comment-16966423 ] Chen commented on COLLECTIONS-546: -- Hello, [~Suryakanth], [~tn], Has this feature been implemented? > Implement expiring queue like already exist PassiveExpiringMap > -- > > Key: COLLECTIONS-546 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-546 > Project: Commons Collections > Issue Type: New Feature > Components: Collection >Affects Versions: 4.x >Reporter: Guram Savinov >Priority: Major > Labels: collection, expiration, queue > > It's very useful collection wrapper for map with expiration - > PassiveExpiringMap. > Can you implement queue with expiration like already exist PassiveExpiringMap? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-563) CircularFifoDequeue
[ https://issues.apache.org/jira/browse/COLLECTIONS-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966576#comment-16966576 ] Chen commented on COLLECTIONS-563: -- Hi, [~belugabehr] , I am very interested in the application scenario of the CircularFifoDequeue，but I don't konw where it can be used, would you like to give a share? > CircularFifoDequeue > --- > > Key: COLLECTIONS-563 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-563 > Project: Commons Collections > Issue Type: Wish > Components: Collection >Reporter: David Mollitor >Priority: Major > Fix For: 4.x > > > I have a need for a CircularFifoDequeue class and I see that Java 1.6 will be > supported now. The CircularFifoDequeue would have the same functionality as > the currently implemented CircularFifoQueue, but can manipulate both sides of > the queue. Of most interest are the abilities to: "descendingIterator," > "peekLast," "removeLastOccurrence." > If an item is ended to the front of the queue throw "not supported" > exception? Remove the item at the back of the queue? > If an item is added to the back of the queue with no space available, the > item at the front of the queue is overwritten. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chen updated COLLECTIONS-663:
-
Comment: was deleted
(was: Hi,[~ggregory]
Read the code, In the AbstractMultiValuedMap.java,
1、AbstractMultiValuedMap.MapIterator() methos will return private
MultiValuedMapIterator class
2、MultiValuedMapIterator class will call
AbstractMultiValuedMap.entries().iterator()
3、AbstractMultiValuedMap.entries() will return private EntryValues class
4、EntryValues class will return LazyIteratorChain overide nextIterator which
call MultiValuedMapEntry class
5、MultiValuedMapEntry class setValue() method throw
UnsupportedOperationException.
so MapIterator.setValue() is not support!
Ithink it is a proplem, Should we solve this problem by submitting a PR?)
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without
> debugging the code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967153#comment-16967153
]
Chen commented on COLLECTIONS-663:
--
Hi，[~chris333]
MapIterator.setValue() really is not supported, there is a not elegant code to
implement your problem what I understand.
{code:java}
//代码占位符
public void testWhatINeedToWork() {
ListValuedMap multiMap = new
ArrayListValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(1, 20);
multiMap.put(2, 10);
System.out.println(multiMap);
for(Collection col: multiMap.asMap().values()){
if(col instanceof List){
List list = (List) col;
for(ListIterator it = list.listIterator(); it.hasNext(); ){
Integer value = (Integer) it.next();
if(value % 2== 0){
it.set(value*2);
}
}
}
}
System.out.println(multiMap);
}
{code}
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without
> debugging the code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967153#comment-16967153
]
Chen edited comment on COLLECTIONS-663 at 11/5/19 1:52 AM:
---
Hi，[~chris333]
MapIterator.setValue() really is not supported, there is a not elegant code to
implement your problem what I understand.
{code:java}
public void testWhatINeedToWork() {
ListValuedMap multiMap = new
ArrayListValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(1, 20);
multiMap.put(2, 10);
System.out.println(multiMap);
for(Collection col: multiMap.asMap().values()){
if(col instanceof List){
List list = (List) col;
for(ListIterator it = list.listIterator(); it.hasNext(); ){
Integer value = (Integer) it.next();
if(value % 2== 0){
it.set(value*2);
}
}
}
}
System.out.println(multiMap);
}
{code}
was (Author: guoping1):
Hi，[~chris333]
MapIterator.setValue() really is not supported, there is a not elegant code to
implement your problem what I understand.
{code:java}
//代码占位符
public void testWhatINeedToWork() {
ListValuedMap multiMap = new
ArrayListValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(1, 20);
multiMap.put(2, 10);
System.out.println(multiMap);
for(Collection col: multiMap.asMap().values()){
if(col instanceof List){
List list = (List) col;
for(ListIterator it = list.listIterator(); it.hasNext(); ){
Integer value = (Integer) it.next();
if(value % 2== 0){
it.set(value*2);
}
}
}
}
System.out.println(multiMap);
}
{code}
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without
> debugging the code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-563) CircularFifoDequeue
[ https://issues.apache.org/jira/browse/COLLECTIONS-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967179#comment-16967179 ] Chen commented on COLLECTIONS-563: -- As per my understanding, array-based unbounded BlockingQueue means it will be blocked only when you take an element from an empty queue, it will never be blocked when you put an element into the queue. I don't understand why you mentioned ArrayDeque, maybe you have other functional requirements, can you explain it in more detail? > CircularFifoDequeue > --- > > Key: COLLECTIONS-563 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-563 > Project: Commons Collections > Issue Type: Wish > Components: Collection >Reporter: David Mollitor >Priority: Major > Fix For: 4.x > > > I have a need for a CircularFifoDequeue class and I see that Java 1.6 will be > supported now. The CircularFifoDequeue would have the same functionality as > the currently implemented CircularFifoQueue, but can manipulate both sides of > the queue. Of most interest are the abilities to: "descendingIterator," > "peekLast," "removeLastOccurrence." > If an item is ended to the front of the queue throw "not supported" > exception? Remove the item at the back of the queue? > If an item is added to the back of the queue with no space available, the > item at the front of the queue is overwritten. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (COLLECTIONS-732) Appeared UnsupportedOperationException when altering MultiValuedMap MapIterator setValue
Chen created COLLECTIONS-732:
Summary: Appeared UnsupportedOperationException when altering
MultiValuedMap MapIterator setValue
Key: COLLECTIONS-732
URL: https://issues.apache.org/jira/browse/COLLECTIONS-732
Project: Commons Collections
Issue Type: Bug
Components: Map
Reporter: Chen
copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
{code:java}
public void testSetValueMapIterator(){
final ListValuedMap listMap = makeObject();
List listA = listMap.get((K) "A");
listA.addAll(0, Arrays.asList((V) "W", (V) "X", (V) "F"));
List listB = listMap.get((K) "B");
listB.addAll(0, Arrays.asList((V) "Q", (V) "Q", (V) "L"));
assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
for(MapIterator iterator = listMap.mapIterator(); iterator.hasNext(); ){
iterator.next();
V value = iterator.getValue();
if(value == "F"){
iterator.setValue((V) "B");
}
}
assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
}
{code}
The test throws a UnsupportedOperationException when altering mapIterato
setValue。
The issue is that the code throws UnsupportedOperationException in
setValue。So，if setValue method is not supported，the Javadoc should comment。
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-732) Got an UnsupportedOperationException when altering MultiValuedMap MapIterator setValue
[
https://issues.apache.org/jira/browse/COLLECTIONS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chen updated COLLECTIONS-732:
-
Summary: Got an UnsupportedOperationException when altering MultiValuedMap
MapIterator setValue (was: Appeared UnsupportedOperationException when
altering MultiValuedMap MapIterator setValue)
> Got an UnsupportedOperationException when altering MultiValuedMap MapIterator
> setValue
> --
>
> Key: COLLECTIONS-732
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-732
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Reporter: Chen
>Priority: Major
>
> copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
> {code:java}
> public void testSetValueMapIterator(){
> final ListValuedMap listMap = makeObject();
> List listA = listMap.get((K) "A");
> listA.addAll(0, Arrays.asList((V) "W", (V) "X", (V) "F"));
> List listB = listMap.get((K) "B");
> listB.addAll(0, Arrays.asList((V) "Q", (V) "Q", (V) "L"));
> assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
> for(MapIterator iterator = listMap.mapIterator(); iterator.hasNext();
> ){
> iterator.next();
> V value = iterator.getValue();
> if(value == "F"){
> iterator.setValue((V) "B");
> }
> }
> assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
> }
> {code}
> The test throws a UnsupportedOperationException when altering mapIterato
> setValue。
> The issue is that the code throws UnsupportedOperationException in
> setValue。So，if setValue method is not supported，the Javadoc should comment。
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-732) Got an UnsupportedOperationException when using MultiValuedMap.MapIterator().setValue()
[
https://issues.apache.org/jira/browse/COLLECTIONS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chen updated COLLECTIONS-732:
-
Summary: Got an UnsupportedOperationException when using
MultiValuedMap.MapIterator().setValue() (was: Got an
UnsupportedOperationException when altering MultiValuedMap MapIterator setValue)
> Got an UnsupportedOperationException when using
> MultiValuedMap.MapIterator().setValue()
> ---
>
> Key: COLLECTIONS-732
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-732
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Reporter: Chen
>Priority: Major
>
> copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
> {code:java}
> public void testSetValueMapIterator(){
> final ListValuedMap listMap = makeObject();
> List listA = listMap.get((K) "A");
> listA.addAll(0, Arrays.asList((V) "W", (V) "X", (V) "F"));
> List listB = listMap.get((K) "B");
> listB.addAll(0, Arrays.asList((V) "Q", (V) "Q", (V) "L"));
> assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
> for(MapIterator iterator = listMap.mapIterator(); iterator.hasNext();
> ){
> iterator.next();
> V value = iterator.getValue();
> if(value == "F"){
> iterator.setValue((V) "B");
> }
> }
> assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
> }
> {code}
> The test throws a UnsupportedOperationException when altering mapIterato
> setValue。
> The issue is that the code throws UnsupportedOperationException in
> setValue。So，if setValue method is not supported，the Javadoc should comment。
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-732) Got an UnsupportedOperationException when using MultiValuedMap.MapIterator().setValue()
[
https://issues.apache.org/jira/browse/COLLECTIONS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chen updated COLLECTIONS-732:
-
Description:
copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
{code:java}
public void testSetValueMapIterator(){
final ListValuedMap listMap = makeObject();
List listA = listMap.get((K) "A");
listA.addAll(0, Arrays.asList((V) "W", (V) "X", (V) "F"));
List listB = listMap.get((K) "B");
listB.addAll(0, Arrays.asList((V) "Q", (V) "Q", (V) "L"));
assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
for(MapIterator iterator = listMap.mapIterator(); iterator.hasNext(); ){
iterator.next();
V value = iterator.getValue();
if(value == "F"){
iterator.setValue((V) "B");
}
}
assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
} throws a UnsupportedOperationException when altering mapIterato
setValue。{code}
The issue is that the code throws UnsupportedOperationException in
setValue。So，if setValue method is not supported，the Javadoc should comment。
was:
copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
{code:java}
public void testSetValueMapIterator(){
final ListValuedMap listMap = makeObject();
List listA = listMap.get((K) "A");
listA.addAll(0, Arrays.asList((V) "W", (V) "X", (V) "F"));
List listB = listMap.get((K) "B");
listB.addAll(0, Arrays.asList((V) "Q", (V) "Q", (V) "L"));
assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
for(MapIterator iterator = listMap.mapIterator(); iterator.hasNext(); ){
iterator.next();
V value = iterator.getValue();
if(value == "F"){
iterator.setValue((V) "B");
}
}
assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
}
{code}
The test throws a UnsupportedOperationException when altering mapIterato
setValue。
The issue is that the code throws UnsupportedOperationException in
setValue。So，if setValue method is not supported，the Javadoc should comment。
> Got an UnsupportedOperationException when using
> MultiValuedMap.MapIterator().setValue()
> ---
>
> Key: COLLECTIONS-732
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-732
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Reporter: Chen
>Priority: Major
>
> copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
> {code:java}
> public void testSetValueMapIterator(){
> final ListValuedMap listMap = makeObject();
> List listA = listMap.get((K) "A");
> listA.addAll(0, Arrays.asList((V) "W", (V) "X", (V) "F"));
> List listB = listMap.get((K) "B");
> listB.addAll(0, Arrays.asList((V) "Q", (V) "Q", (V) "L"));
> assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
> for(MapIterator iterator = listMap.mapIterator(); iterator.hasNext();
> ){
> iterator.next();
> V value = iterator.getValue();
> if(value == "F"){
> iterator.setValue((V) "B");
> }
> }
> assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
> } throws a UnsupportedOperationException when altering mapIterato
> setValue。{code}
> The issue is that the code throws UnsupportedOperationException in
> setValue。So，if setValue method is not supported，the Javadoc should comment。
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-732) Got an UnsupportedOperationException when using MultiValuedMap.MapIterator().setValue()
[
https://issues.apache.org/jira/browse/COLLECTIONS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chen updated COLLECTIONS-732:
-
Description:
copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
{code:java}
public void testSetValueMapIterator(){
final ListValuedMap listMap = makeObject();
List listA = listMap.get((K) "A");
listA.addAll(0, Arrays.asList((V) "W", (V) "X", (V) "F"));
List listB = listMap.get((K) "B");
listB.addAll(0, Arrays.asList((V) "Q", (V) "Q", (V) "L"));
assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
for(MapIterator iterator = listMap.mapIterator(); iterator.hasNext(); ){
iterator.next();
V value = iterator.getValue();
if(value == "F"){
iterator.setValue((V) "B");
}
}
assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
}
{code}
It throws an UnsupportedOperationException when altering
mapIterator().setValue()。
I found UnsupportedOperationException is thrown in the code of setValue。So，if
setValue method is not supported，the Javadoc should comment it。
was:
copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
{code:java}
public void testSetValueMapIterator(){
final ListValuedMap listMap = makeObject();
List listA = listMap.get((K) "A");
listA.addAll(0, Arrays.asList((V) "W", (V) "X", (V) "F"));
List listB = listMap.get((K) "B");
listB.addAll(0, Arrays.asList((V) "Q", (V) "Q", (V) "L"));
assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
for(MapIterator iterator = listMap.mapIterator(); iterator.hasNext(); ){
iterator.next();
V value = iterator.getValue();
if(value == "F"){
iterator.setValue((V) "B");
}
}
assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
} throws a UnsupportedOperationException when altering mapIterato
setValue。{code}
The issue is that the code throws UnsupportedOperationException in
setValue。So，if setValue method is not supported，the Javadoc should comment。
> Got an UnsupportedOperationException when using
> MultiValuedMap.MapIterator().setValue()
> ---
>
> Key: COLLECTIONS-732
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-732
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Reporter: Chen
>Priority: Major
>
> copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
> {code:java}
> public void testSetValueMapIterator(){
> final ListValuedMap listMap = makeObject();
> List listA = listMap.get((K) "A");
> listA.addAll(0, Arrays.asList((V) "W", (V) "X", (V) "F"));
> List listB = listMap.get((K) "B");
> listB.addAll(0, Arrays.asList((V) "Q", (V) "Q", (V) "L"));
> assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
> for(MapIterator iterator = listMap.mapIterator(); iterator.hasNext();
> ){
> iterator.next();
> V value = iterator.getValue();
> if(value == "F"){
> iterator.setValue((V) "B");
> }
> }
> assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
> }
> {code}
> It throws an UnsupportedOperationException when altering
> mapIterator().setValue()。
> I found UnsupportedOperationException is thrown in the code of setValue。So，if
> setValue method is not supported，the Javadoc should comment it。
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-732) Got an UnsupportedOperationException when using MultiValuedMap.MapIterator().setValue()
[
https://issues.apache.org/jira/browse/COLLECTIONS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chen updated COLLECTIONS-732:
-
Description:
copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
{code:java}
public void testSetValueMapIterator(){
final ListValuedMap listMap = new
ArrayListValuedHashMap<>();
List listA = listMap.get("A");
listA.addAll(0, Arrays.asList("W", "X", "F"));
List listB = listMap.get("B");
listB.addAll(0, Arrays.asList("Q", "Q", "L"));
assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
for(MapIterator iterator = listMap.mapIterator();
iterator.hasNext(); ){
iterator.next();
String value = iterator.getValue();
if(value == "F"){
iterator.setValue("B");
}
}
assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
}
{code}
It throws an UnsupportedOperationException when altering
mapIterator().setValue()。
I found UnsupportedOperationException is thrown in the code of setValue。So，if
setValue method is not supported，the Javadoc should comment it。
was:
copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
{code:java}
public void testSetValueMapIterator(){
final ListValuedMap listMap = makeObject();
List listA = listMap.get((K) "A");
listA.addAll(0, Arrays.asList((V) "W", (V) "X", (V) "F"));
List listB = listMap.get((K) "B");
listB.addAll(0, Arrays.asList((V) "Q", (V) "Q", (V) "L"));
assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
for(MapIterator iterator = listMap.mapIterator(); iterator.hasNext(); ){
iterator.next();
V value = iterator.getValue();
if(value == "F"){
iterator.setValue((V) "B");
}
}
assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
}
{code}
It throws an UnsupportedOperationException when altering
mapIterator().setValue()。
I found UnsupportedOperationException is thrown in the code of setValue。So，if
setValue method is not supported，the Javadoc should comment it。
> Got an UnsupportedOperationException when using
> MultiValuedMap.MapIterator().setValue()
> ---
>
> Key: COLLECTIONS-732
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-732
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Reporter: Chen
>Priority: Major
>
> copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
> {code:java}
> public void testSetValueMapIterator(){
> final ListValuedMap listMap = new
> ArrayListValuedHashMap<>();
> List listA = listMap.get("A");
> listA.addAll(0, Arrays.asList("W", "X", "F"));
> List listB = listMap.get("B");
> listB.addAll(0, Arrays.asList("Q", "Q", "L"));
> assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
> for(MapIterator iterator = listMap.mapIterator();
> iterator.hasNext(); ){
> iterator.next();
> String value = iterator.getValue();
> if(value == "F"){
> iterator.setValue("B");
> }
> }
> assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
> }
> {code}
> It throws an UnsupportedOperationException when altering
> mapIterator().setValue()。
> I found UnsupportedOperationException is thrown in the code of setValue。So，if
> setValue method is not supported，the Javadoc should comment it。
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968061#comment-16968061
]
Chen commented on COLLECTIONS-663:
--
Hello. [~chris333]
Thank you for response.
I think the representation of Multimap is \{1: A, 1: B, 2: C}. So when A and B
are deleted, only \{2: C} is left. And asMap() method is return a map in the
form of \{1：[A, B], 2：[C]}. In this map, \{1：[], 2:[C]} is left when a and B
are deleted.
If you agree with what I say above, the cause of the problem is not
AbstractMultiMap ValueIterator.remove();
The reasons are as follows:
{code:java}
// AbstractMultiValuedMap AsMap entrySet() AsMapEntrySet AsMapEntrySetIterator
next()
class AsMapEntrySetIterator extends
AbstractIteratorDecorator>> {
AsMapEntrySetIterator(final Iterator>>
iterator) {
super(iterator);
}
@Override
public Map.Entry> next() {
final Map.Entry> entry = super.next();
final K key = entry.getKey();
final Collection value = entry.getValue();
return new UnmodifiableMapEntry<>(key, value);
//return new UnmodifiableMapEntry<>(key,
wrappedCollection(key));
}
}
{code}
I think wrappedCollection(key) should not be used。if it use
wrappedCollection(key), it willl be shown as \{1: A, 1: B, 2: C}. the asMap()
method does not make sense.
Thank for your listening!
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without
> debugging the code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968061#comment-16968061
]
Chen edited comment on COLLECTIONS-663 at 11/6/19 6:09 AM:
---
Hello. [~chris333]
Thank you for your response.
I think the representation of Multimap is \{1: A, 1: B, 2: C}. So when A and B
are deleted, only \{2: C} is left. And asMap() method is return a map in the
form of {1：[A, B], 2：[C]}. In this map, {1：[], 2:[C]} is left when a and B are
deleted.
If you agree with what I say above, the cause of the problem is not
AbstractMultiMap ValueIterator.remove();
The reasons are as follows:
{code:java}
// AbstractMultiValuedMap AsMap entrySet() AsMapEntrySet AsMapEntrySetIterator
next()
class AsMapEntrySetIterator extends
AbstractIteratorDecorator>> {
AsMapEntrySetIterator(final Iterator>>
iterator) {
super(iterator);
}
@Override
public Map.Entry> next() {
final Map.Entry> entry = super.next();
final K key = entry.getKey();
final Collection value = entry.getValue();
return new UnmodifiableMapEntry<>(key, value);
//return new UnmodifiableMapEntry<>(key,
wrappedCollection(key));
}
}
{code}
I think wrappedCollection(key) should not be used。if it use
wrappedCollection(key), it willl be shown as \{1: A, 1: B, 2: C}. the asMap()
method does not make sense. And this modification will also avoid your problem.
Thank you for your listening!
was (Author: guoping1):
Hello. [~chris333]
Thank you for response.
I think the representation of Multimap is \{1: A, 1: B, 2: C}. So when A and B
are deleted, only \{2: C} is left. And asMap() method is return a map in the
form of \{1：[A, B], 2：[C]}. In this map, \{1：[], 2:[C]} is left when a and B
are deleted.
If you agree with what I say above, the cause of the problem is not
AbstractMultiMap ValueIterator.remove();
The reasons are as follows:
{code:java}
// AbstractMultiValuedMap AsMap entrySet() AsMapEntrySet AsMapEntrySetIterator
next()
class AsMapEntrySetIterator extends
AbstractIteratorDecorator>> {
AsMapEntrySetIterator(final Iterator>>
iterator) {
super(iterator);
}
@Override
public Map.Entry> next() {
final Map.Entry> entry = super.next();
final K key = entry.getKey();
final Collection value = entry.getValue();
return new UnmodifiableMapEntry<>(key, value);
//return new UnmodifiableMapEntry<>(key,
wrappedCollection(key));
}
}
{code}
I think wrappedCollection(key) should not be used。if it use
wrappedCollection(key), it willl be shown as \{1: A, 1: B, 2: C}. the asMap()
method does not make sense.
Thank for your listening!
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without
> debugging the code.
--
This message
[jira] [Comment Edited] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968061#comment-16968061
]
Chen edited comment on COLLECTIONS-663 at 11/6/19 6:10 AM:
---
Hello. [~chris333]
Thank you for your response.
I think the representation of Multimap is \{1: A, 1: B, 2: C}. So when A and B
are deleted, only \{2: C} is left. And asMap() method is return a map in the
form of \{1：[A, B], 2：[C]}. In this map, \{1：[], 2:[C]} is left when A and B
are deleted.
If you agree with what I say above, the cause of the problem is not
AbstractMultiMap ValueIterator.remove().
The reasons are as follows:
{code:java}
// AbstractMultiValuedMap AsMap entrySet() AsMapEntrySet AsMapEntrySetIterator
next()
class AsMapEntrySetIterator extends
AbstractIteratorDecorator>> {
AsMapEntrySetIterator(final Iterator>>
iterator) {
super(iterator);
}
@Override
public Map.Entry> next() {
final Map.Entry> entry = super.next();
final K key = entry.getKey();
final Collection value = entry.getValue();
return new UnmodifiableMapEntry<>(key, value);
//return new UnmodifiableMapEntry<>(key,
wrappedCollection(key));
}
}
{code}
I think wrappedCollection(key) should not be used。if it use
wrappedCollection(key), it willl be shown as \{1: A, 1: B, 2: C}. the asMap()
method does not make sense. And this modification will also avoid your problem.
Thank you for your listening!
was (Author: guoping1):
Hello. [~chris333]
Thank you for your response.
I think the representation of Multimap is \{1: A, 1: B, 2: C}. So when A and B
are deleted, only \{2: C} is left. And asMap() method is return a map in the
form of {1：[A, B], 2：[C]}. In this map, {1：[], 2:[C]} is left when a and B are
deleted.
If you agree with what I say above, the cause of the problem is not
AbstractMultiMap ValueIterator.remove();
The reasons are as follows:
{code:java}
// AbstractMultiValuedMap AsMap entrySet() AsMapEntrySet AsMapEntrySetIterator
next()
class AsMapEntrySetIterator extends
AbstractIteratorDecorator>> {
AsMapEntrySetIterator(final Iterator>>
iterator) {
super(iterator);
}
@Override
public Map.Entry> next() {
final Map.Entry> entry = super.next();
final K key = entry.getKey();
final Collection value = entry.getValue();
return new UnmodifiableMapEntry<>(key, value);
//return new UnmodifiableMapEntry<>(key,
wrappedCollection(key));
}
}
{code}
I think wrappedCollection(key) should not be used。if it use
wrappedCollection(key), it willl be shown as \{1: A, 1: B, 2: C}. the asMap()
method does not make sense. And this modification will also avoid your problem.
Thank you for your listening!
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is
[jira] [Comment Edited] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968061#comment-16968061
]
Chen edited comment on COLLECTIONS-663 at 11/6/19 6:27 AM:
---
Hello. [~chris333]
Thank you for your response.
I think the representation of Multimap is \{1: A, 1: B, 2: C}. So when A and B
are deleted, only \{2: C} is left. And asMap() method returns a map in the
form of {1：[A, B], 2：[C]}. In this map, {1：[], 2:[C]} is left when A and B are
deleted.
If you agree with what I say above, the cause of your problem is not
AbstractMultiMap ValueIterator.remove().
The reason is as follow:
{code:java}
// AbstractMultiValuedMap AsMap entrySet() AsMapEntrySet AsMapEntrySetIterator
next()
class AsMapEntrySetIterator extends
AbstractIteratorDecorator>> {
AsMapEntrySetIterator(final Iterator>>
iterator) {
super(iterator);
}
@Override
public Map.Entry> next() {
final Map.Entry> entry = super.next();
final K key = entry.getKey();
final Collection value = entry.getValue();
return new UnmodifiableMapEntry<>(key, value);
//return new UnmodifiableMapEntry<>(key,
wrappedCollection(key));
}
}
{code}
I think wrappedCollection(key) should not be used。 It willl be shown as \{1: A,
1: B, 2: C} when wrappedCollection(key) is used, the asMap() method does not
make sense.
And this modification will also avoid your problem.
Thank you for your listening!
was (Author: guoping1):
Hello. [~chris333]
Thank you for your response.
I think the representation of Multimap is \{1: A, 1: B, 2: C}. So when A and B
are deleted, only \{2: C} is left. And asMap() method is return a map in the
form of \{1：[A, B], 2：[C]}. In this map, \{1：[], 2:[C]} is left when A and B
are deleted.
If you agree with what I say above, the cause of the problem is not
AbstractMultiMap ValueIterator.remove().
The reasons are as follows:
{code:java}
// AbstractMultiValuedMap AsMap entrySet() AsMapEntrySet AsMapEntrySetIterator
next()
class AsMapEntrySetIterator extends
AbstractIteratorDecorator>> {
AsMapEntrySetIterator(final Iterator>>
iterator) {
super(iterator);
}
@Override
public Map.Entry> next() {
final Map.Entry> entry = super.next();
final K key = entry.getKey();
final Collection value = entry.getValue();
return new UnmodifiableMapEntry<>(key, value);
//return new UnmodifiableMapEntry<>(key,
wrappedCollection(key));
}
}
{code}
I think wrappedCollection(key) should not be used。if it use
wrappedCollection(key), it willl be shown as \{1: A, 1: B, 2: C}. the asMap()
method does not make sense. And this modification will also avoid your problem.
Thank you for your listening!
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is
[jira] [Comment Edited] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968061#comment-16968061
]
Chen edited comment on COLLECTIONS-663 at 11/6/19 6:31 AM:
---
Hello. [~chris333]
Thank you for your response.
I think the representation of Multimap is \{1: A, 1: B, 2: C}. So when A and B
are deleted, only \{2: C} is left. And asMap() method returns a map in the
form of \{1：[A, B], 2：[C]}. In this map, \{1：[], 2:[C]} is left when A and B
are deleted.
If you agree with what I say above, the cause of your problem is not
AbstractMultiMap ValueIterator.remove().
The reason is as follow:
{code:java}
// AbstractMultiValuedMap AsMap entrySet() AsMapEntrySet AsMapEntrySetIterator
next()
class AsMapEntrySetIterator extends
AbstractIteratorDecorator>> {
AsMapEntrySetIterator(final Iterator>>
iterator) {
super(iterator);
}
@Override
public Map.Entry> next() {
final Map.Entry> entry = super.next();
final K key = entry.getKey();
final Collection value = entry.getValue();
return new UnmodifiableMapEntry<>(key, value);
//return new UnmodifiableMapEntry<>(key,
wrappedCollection(key));
}
}
{code}
I think wrappedCollection(key) should not be used。 It willl be shown as \{1: A,
1: B, 2: C} when wrappedCollection(key) is used, the asMap() method does not
make sense.
And this modification will also avoid your problem. You also can traverse the
MultiMap by mapIterator() method.
Thank you for your listening!
was (Author: guoping1):
Hello. [~chris333]
Thank you for your response.
I think the representation of Multimap is \{1: A, 1: B, 2: C}. So when A and B
are deleted, only \{2: C} is left. And asMap() method returns a map in the
form of {1：[A, B], 2：[C]}. In this map, {1：[], 2:[C]} is left when A and B are
deleted.
If you agree with what I say above, the cause of your problem is not
AbstractMultiMap ValueIterator.remove().
The reason is as follow:
{code:java}
// AbstractMultiValuedMap AsMap entrySet() AsMapEntrySet AsMapEntrySetIterator
next()
class AsMapEntrySetIterator extends
AbstractIteratorDecorator>> {
AsMapEntrySetIterator(final Iterator>>
iterator) {
super(iterator);
}
@Override
public Map.Entry> next() {
final Map.Entry> entry = super.next();
final K key = entry.getKey();
final Collection value = entry.getValue();
return new UnmodifiableMapEntry<>(key, value);
//return new UnmodifiableMapEntry<>(key,
wrappedCollection(key));
}
}
{code}
I think wrappedCollection(key) should not be used。 It willl be shown as \{1: A,
1: B, 2: C} when wrappedCollection(key) is used, the asMap() method does not
make sense.
And this modification will also avoid your problem.
Thank you for your listening!
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now empty collection (which was removed from the parent).
>
[jira] [Comment Edited] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968061#comment-16968061
]
Chen edited comment on COLLECTIONS-663 at 11/6/19 6:36 AM:
---
Hello. [~chris333]
Thank you for your response.
I think the representation of Multimap is \{1: A, 1: B, 2: C}. So when A and B
are deleted, only \{2: C} is left. And asMap() method returns a map in the
form of {1：[A, B], 2：[C]}. In this map, {1：[], 2:[C]} is left when A and B are
deleted.
If you agree with what I say above, the cause of your problem is not
AbstractMultiMap ValueIterator.remove().
The reason is as follow:
{code:java}
// AbstractMultiValuedMap AsMap entrySet() AsMapEntrySet AsMapEntrySetIterator
next()
class AsMapEntrySetIterator extends
AbstractIteratorDecorator>> {
AsMapEntrySetIterator(final Iterator>>
iterator) {
super(iterator);
}
@Override
public Map.Entry> next() {
final Map.Entry> entry = super.next();
final K key = entry.getKey();
final Collection value = entry.getValue();
return new UnmodifiableMapEntry<>(key, value);
//return new UnmodifiableMapEntry<>(key,
wrappedCollection(key));
}
}
{code}
I think wrappedCollection(key) should not be used。 It willl show as \{1: A, 1:
B, 2: C} when wrappedCollection(key) is used, the asMap() method does not make
sense.
And this modification will also avoid your problem. You also can traverse the
MultiMap by mapIterator() method.
Thank you for your listening!
was (Author: guoping1):
Hello. [~chris333]
Thank you for your response.
I think the representation of Multimap is \{1: A, 1: B, 2: C}. So when A and B
are deleted, only \{2: C} is left. And asMap() method returns a map in the
form of \{1：[A, B], 2：[C]}. In this map, \{1：[], 2:[C]} is left when A and B
are deleted.
If you agree with what I say above, the cause of your problem is not
AbstractMultiMap ValueIterator.remove().
The reason is as follow:
{code:java}
// AbstractMultiValuedMap AsMap entrySet() AsMapEntrySet AsMapEntrySetIterator
next()
class AsMapEntrySetIterator extends
AbstractIteratorDecorator>> {
AsMapEntrySetIterator(final Iterator>>
iterator) {
super(iterator);
}
@Override
public Map.Entry> next() {
final Map.Entry> entry = super.next();
final K key = entry.getKey();
final Collection value = entry.getValue();
return new UnmodifiableMapEntry<>(key, value);
//return new UnmodifiableMapEntry<>(key,
wrappedCollection(key));
}
}
{code}
I think wrappedCollection(key) should not be used。 It willl be shown as \{1: A,
1: B, 2: C} when wrappedCollection(key) is used, the asMap() method does not
make sense.
And this modification will also avoid your problem. You also can traverse the
MultiMap by mapIterator() method.
Thank you for your listening!
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this no
[jira] [Comment Edited] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968061#comment-16968061
]
Chen edited comment on COLLECTIONS-663 at 11/6/19 7:07 AM:
---
Hello. [~chris333]
Thank you for your response.
I think the representation of Multimap is \{1: A, 1: B, 2: C}. So when A and B
are deleted, only \{2: C} is left. And asMap() method returns a map in the
form of \{1：[A, B], 2：[C]}. In this map, \{1：[], 2:[C]} is left when A and B
are deleted.
If you agree with what I say above, the cause of your problem is not
AbstractMultiMap ValueIterator.remove().
The reason is as follow:
{code:java}
// AbstractMultiValuedMap AsMap entrySet() AsMapEntrySet AsMapEntrySetIterator
next()
class AsMapEntrySetIterator extends
AbstractIteratorDecorator>> {
AsMapEntrySetIterator(final Iterator>>
iterator) {
super(iterator);
}
@Override
public Map.Entry> next() {
final Map.Entry> entry = super.next();
final K key = entry.getKey();
final Collection value = entry.getValue();
return new UnmodifiableMapEntry<>(key, value);
//return new UnmodifiableMapEntry<>(key,
wrappedCollection(key));
}
}
{code}
I think wrappedCollection(key) should not be used。 It willl show as \{1: A, 1:
B, 2: C} when wrappedCollection(key) is used, the asMap() method does not make
sense.
And this modification will also avoid your problem. You also can traverse the
MultiMap by mapIterator() method.
Thank you for your listening!
was (Author: guoping1):
Hello. [~chris333]
Thank you for your response.
I think the representation of Multimap is \{1: A, 1: B, 2: C}. So when A and B
are deleted, only \{2: C} is left. And asMap() method returns a map in the
form of {1：[A, B], 2：[C]}. In this map, {1：[], 2:[C]} is left when A and B are
deleted.
If you agree with what I say above, the cause of your problem is not
AbstractMultiMap ValueIterator.remove().
The reason is as follow:
{code:java}
// AbstractMultiValuedMap AsMap entrySet() AsMapEntrySet AsMapEntrySetIterator
next()
class AsMapEntrySetIterator extends
AbstractIteratorDecorator>> {
AsMapEntrySetIterator(final Iterator>>
iterator) {
super(iterator);
}
@Override
public Map.Entry> next() {
final Map.Entry> entry = super.next();
final K key = entry.getKey();
final Collection value = entry.getValue();
return new UnmodifiableMapEntry<>(key, value);
//return new UnmodifiableMapEntry<>(key,
wrappedCollection(key));
}
}
{code}
I think wrappedCollection(key) should not be used。 It willl show as \{1: A, 1:
B, 2: C} when wrappedCollection(key) is used, the asMap() method does not make
sense.
And this modification will also avoid your problem. You also can traverse the
MultiMap by mapIterator() method.
Thank you for your listening!
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now em
[jira] [Comment Edited] (COLLECTIONS-733) Thread-Safe Array Blocking Deque
[
https://issues.apache.org/jira/browse/COLLECTIONS-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16970694#comment-16970694
]
Chen edited comment on COLLECTIONS-733 at 11/9/19 2:54 AM:
---
Do you want a queue or a deque?
"What I have had the need for several times now is a resizable-array
implementation of a bounded blocking queue. It should implement all the same
methods as the ArrayBlockingQueue but it can grow as needed, like an
ArrayDeque."
I think you can use a wrapper class which contains an ArrayBlockingQueue
variable and a reSizeQueue() method, you can use the method to creat a new
bigger size ArrayBlockingQueue to the variable when you want to resize the
queue.
If this can solve your problem?
was (Author: guoping1):
Do you want a queue or a deque?
"What I have had the need for several times now is a resizable-array
implementation of a bounded blocking queue. It should implement all the same
methods as the ArrayBlockingQueue but it can grow as needed, like an
ArrayDeque."
I think you can use a wrapper class which contains a ArrayBlockingQueue
variable and a reSizeQueue() method, you can use the method to creat a new
bigger size ArrayBlockingQueue to the variable when you want to resize the
queue.
If this can solve your problem?
> Thread-Safe Array Blocking Deque
>
>
> Key: COLLECTIONS-733
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-733
> Project: Commons Collections
> Issue Type: New Feature
>Reporter: David Mollitor
>Priority: Major
>
> The JDK offers an
> [ArrayDeque|https://docs.oracle.com/javase/8/docs/api/java/util/ArrayDeque.html]
> which is a resizable-array implementation of the
> [Deque|https://docs.oracle.com/javase/8/docs/api/java/util/Deque.html]
> interface.
> The JDK also offers an
> [ArrayBlockingQueue|https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ArrayBlockingQueue.html]
> which is a bounded blocking queue backed by an array.
> What I have had the need for several times now is a resizable-array
> implementation of a bounded blocking queue. It should implement all the same
> methods as the {{ArrayBlockingQueue}} but it can grow as needed, like an
> {{ArrayDeque}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-733) Thread-Safe Array Blocking Deque
[
https://issues.apache.org/jira/browse/COLLECTIONS-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16970694#comment-16970694
]
Chen commented on COLLECTIONS-733:
--
Do you want a queue or a deque?
"What I have had the need for several times now is a resizable-array
implementation of a bounded blocking queue. It should implement all the same
methods as the ArrayBlockingQueue but it can grow as needed, like an
ArrayDeque."
I think you can use a wrapper class which contains a ArrayBlockingQueue
variable and a reSizeQueue() method, you can use the method to creat a new
bigger size ArrayBlockingQueue to the variable when you want to resize the
queue.
If this can solve your problem?
> Thread-Safe Array Blocking Deque
>
>
> Key: COLLECTIONS-733
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-733
> Project: Commons Collections
> Issue Type: New Feature
>Reporter: David Mollitor
>Priority: Major
>
> The JDK offers an
> [ArrayDeque|https://docs.oracle.com/javase/8/docs/api/java/util/ArrayDeque.html]
> which is a resizable-array implementation of the
> [Deque|https://docs.oracle.com/javase/8/docs/api/java/util/Deque.html]
> interface.
> The JDK also offers an
> [ArrayBlockingQueue|https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ArrayBlockingQueue.html]
> which is a bounded blocking queue backed by an array.
> What I have had the need for several times now is a resizable-array
> implementation of a bounded blocking queue. It should implement all the same
> methods as the {{ArrayBlockingQueue}} but it can grow as needed, like an
> {{ArrayDeque}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-733) Thread-Safe Array Blocking Deque
[
https://issues.apache.org/jira/browse/COLLECTIONS-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16970694#comment-16970694
]
Chen edited comment on COLLECTIONS-733 at 11/9/19 2:55 AM:
---
Do you want a queue or a deque?
"What I have had the need for several times now is a resizable-array
implementation of a bounded blocking queue. It should implement all the same
methods as the ArrayBlockingQueue but it can grow as needed, like an
ArrayDeque."
I think you can use a wrapper class which contains an ArrayBlockingQueue
variable and a resizeQueue() method, you can use the method to creat a new
bigger size ArrayBlockingQueue to the variable when you want to resize the
queue.
If this can solve your problem?
was (Author: guoping1):
Do you want a queue or a deque?
"What I have had the need for several times now is a resizable-array
implementation of a bounded blocking queue. It should implement all the same
methods as the ArrayBlockingQueue but it can grow as needed, like an
ArrayDeque."
I think you can use a wrapper class which contains an ArrayBlockingQueue
variable and a reSizeQueue() method, you can use the method to creat a new
bigger size ArrayBlockingQueue to the variable when you want to resize the
queue.
If this can solve your problem?
> Thread-Safe Array Blocking Deque
>
>
> Key: COLLECTIONS-733
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-733
> Project: Commons Collections
> Issue Type: New Feature
>Reporter: David Mollitor
>Priority: Major
>
> The JDK offers an
> [ArrayDeque|https://docs.oracle.com/javase/8/docs/api/java/util/ArrayDeque.html]
> which is a resizable-array implementation of the
> [Deque|https://docs.oracle.com/javase/8/docs/api/java/util/Deque.html]
> interface.
> The JDK also offers an
> [ArrayBlockingQueue|https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ArrayBlockingQueue.html]
> which is a bounded blocking queue backed by an array.
> What I have had the need for several times now is a resizable-array
> implementation of a bounded blocking queue. It should implement all the same
> methods as the {{ArrayBlockingQueue}} but it can grow as needed, like an
> {{ArrayDeque}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-733) Thread-Safe Array Blocking Deque
[
https://issues.apache.org/jira/browse/COLLECTIONS-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16971287#comment-16971287
]
Chen commented on COLLECTIONS-733:
--
Maybe you can use a wrapper of ArrayBlockingQueue, check the capacity before
pushing an element into the queue, if the queue is full, creat a new bigger
ArrayBlockingQueue. Operations can only be blocked when the queue is empty. Is
this queue what you want?
> Thread-Safe Array Blocking Deque
>
>
> Key: COLLECTIONS-733
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-733
> Project: Commons Collections
> Issue Type: New Feature
>Reporter: David Mollitor
>Priority: Major
>
> The JDK offers an
> [ArrayDeque|https://docs.oracle.com/javase/8/docs/api/java/util/ArrayDeque.html]
> which is a resizable-array implementation of the
> [Deque|https://docs.oracle.com/javase/8/docs/api/java/util/Deque.html]
> interface.
> The JDK also offers an
> [ArrayBlockingQueue|https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ArrayBlockingQueue.html]
> which is a bounded blocking queue backed by an array.
> What I have had the need for several times now is a resizable-array
> implementation of a bounded blocking queue. It should implement all the same
> methods as the {{ArrayBlockingQueue}} but it can grow as needed, like an
> {{ArrayDeque}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (COLLECTIONS-734) Encountered an IllegalStateException while traversing with Flat3Map.entrySet()
Chen created COLLECTIONS-734:
Summary: Encountered an IllegalStateException while traversing
with Flat3Map.entrySet()
Key: COLLECTIONS-734
URL: https://issues.apache.org/jira/browse/COLLECTIONS-734
Project: Commons Collections
Issue Type: Bug
Components: Map
Affects Versions: 3.0
Reporter: Chen
Encountered an IllegalStateException while traversing with Flat3Map.entrySet()
{code:java}
//代码示例
public void testEntrySet() {
final Flat3Map map = new Flat3Map<>();
map.put(1, "A");
map.put(2, "B");
map.put(3, "C");
Iterator> it = map.entrySet().iterator();
Map.Entry mapEntry1 = it.next();
Map.Entry mapEntry2 = it.next();
Map.Entry mapEntry3 = it.next();
it.remove();assertEquals(2, map.size());
}
{code}
Using the above code will generate an IllegalStateException.
The reason for this problem is that there is a problem with the
EntryIterator.remove() method in the Flat3Map java class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-734) Encountered an IllegalStateException while traversing with Flat3Map.entrySet()
[
https://issues.apache.org/jira/browse/COLLECTIONS-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chen updated COLLECTIONS-734:
-
Description:
Encountered an IllegalStateException while traversing with Flat3Map.entrySet()
{code:java}
//代码示例
public void testEntrySet() {
final Flat3Map map = new Flat3Map<>();
map.put(1, "A");
map.put(2, "B");
map.put(3, "C");
Iterator> it = map.entrySet().iterator();
Map.Entry mapEntry1 = it.next();
Map.Entry mapEntry2 = it.next();
Map.Entry mapEntry3 = it.next();
it.remove();assertEquals(2, map.size());
}
{code}
Using the above code will generate an IllegalStateException.
The reason for this problem is that there is a problem with the
EntryIterator.remove() method in the Flat3Map java class.
I submitted a
[PR|https://github.com/apache/commons-collections/pull/115](https://github.com/apache/commons-collections/pull/115)
to fix this bug.
was:
Encountered an IllegalStateException while traversing with Flat3Map.entrySet()
{code:java}
//代码示例
public void testEntrySet() {
final Flat3Map map = new Flat3Map<>();
map.put(1, "A");
map.put(2, "B");
map.put(3, "C");
Iterator> it = map.entrySet().iterator();
Map.Entry mapEntry1 = it.next();
Map.Entry mapEntry2 = it.next();
Map.Entry mapEntry3 = it.next();
it.remove();assertEquals(2, map.size());
}
{code}
Using the above code will generate an IllegalStateException.
The reason for this problem is that there is a problem with the
EntryIterator.remove() method in the Flat3Map java class.
> Encountered an IllegalStateException while traversing with
> Flat3Map.entrySet()
> ---
>
> Key: COLLECTIONS-734
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-734
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Affects Versions: 3.0
>Reporter: Chen
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Encountered an IllegalStateException while traversing with
> Flat3Map.entrySet()
> {code:java}
> //代码示例
> public void testEntrySet() {
> final Flat3Map map = new Flat3Map<>();
> map.put(1, "A");
> map.put(2, "B");
> map.put(3, "C");
> Iterator> it = map.entrySet().iterator();
> Map.Entry mapEntry1 = it.next();
> Map.Entry mapEntry2 = it.next();
> Map.Entry mapEntry3 = it.next();
> it.remove();assertEquals(2, map.size());
> }
> {code}
> Using the above code will generate an IllegalStateException.
> The reason for this problem is that there is a problem with the
> EntryIterator.remove() method in the Flat3Map java class.
> I submitted a
> [PR|https://github.com/apache/commons-collections/pull/115](https://github.com/apache/commons-collections/pull/115)
> to fix this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-604) More uniform safe-null methods in CollectionUtils
[
https://issues.apache.org/jira/browse/COLLECTIONS-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16972176#comment-16972176
]
Chen commented on COLLECTIONS-604:
--
Refer to java.util.Objects.requireNonNull?
> More uniform safe-null methods in CollectionUtils
> -
>
> Key: COLLECTIONS-604
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-604
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 4.1
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Attachments: COLLECTIONS-604.csv
>
>
> Currently, there are 65 public methods in `CollectionUtils`. And 53 without
> the deprecated ones. Out of these, 24 handle `null` arguments. The remaining
> methods throw a `NullPointerException` (NPE) at some part of its code.
> The methods that handle nulls, throw NPE, or return empty columns, boolean
> values, or just doesn't do anything.
> As a user of the API, I would expect a more uniform behaviour across the
> methods of `CollectionUtils`. COLLECTIONS-600 address one of these methods.
> `removeAll` (2x) and `retainAll` (2x) both state that a NPE will be thrown if
> either parameter is `null`. However, they never check if the values are null,
> and instead allow the code to run until a NPE is thrown.
> And the following code shows that `isEmpty` and `isFull` behave differently
> too.
> {code:java}
> Collection c = null;
> System.out.println(CollectionUtils.isEmpty(c)); // return true
> System.out.println(CollectionUtils.isFull(c)); // throws a NPE
> {code}
> If I don't have to worry about `null`s with `#isEmpty`, I would expect the
> same from its related-method `#isFull`.
> What would be a good approach for it? Define a behaviour to all methods? Or
> leave as is, but add more documentation?
> There are a few methods that can easily be updated to check for `null`
> values. Others would require a bit more thinking. An example if the method in
> question for COLLECTIONS-600. It checks equality of collections, and when
> both collections are `null`, it says that they are equals. Google Guava
> [Iterables#elementsEqual|https://github.com/google/guava/blob/312aeb938bd35b5b7c8930e19ff5d1ca38e49424/guava/src/com/google/common/collect/Iterables.java#L232]
> and
> [Iterators#elementsEqual|https://github.com/google/guava/blob/312aeb938bd35b5b7c8930e19ff5d1ca38e49424/guava/src/com/google/common/collect/Iterators.java#L274]
> do not check for null values, for what it is worth.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (COLLECTIONS-546) Implement expiring queue like already exist PassiveExpiringMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chen updated COLLECTIONS-546: - Comment: was deleted (was: Hello, [~Suryakanth], [~tn], Has this feature been implemented?) > Implement expiring queue like already exist PassiveExpiringMap > -- > > Key: COLLECTIONS-546 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-546 > Project: Commons Collections > Issue Type: New Feature > Components: Collection >Affects Versions: 4.x >Reporter: Guram Savinov >Priority: Major > Labels: collection, expiration, queue > > It's very useful collection wrapper for map with expiration - > PassiveExpiringMap. > Can you implement queue with expiration like already exist PassiveExpiringMap? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-546) Implement expiring queue like already exist PassiveExpiringMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16974002#comment-16974002 ] Chen commented on COLLECTIONS-546: -- Hi, [~gsavinov] PassiveExpiringMap can be used to implement caching, and most of the caching is also based on map storage. Does PassiveExpiringQueue have a usage scenario? In keeping with PassiveExpiringMap, the PassiveExpiringQueue should be implemented as a class that decorates the queue, not a concrete queue class. But this decorative queue is not only difficult to implement but also not very useful. There is a delayQueue which is a concrete queue in jdk that might suit you! > Implement expiring queue like already exist PassiveExpiringMap > -- > > Key: COLLECTIONS-546 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-546 > Project: Commons Collections > Issue Type: New Feature > Components: Collection >Affects Versions: 4.x >Reporter: Guram Savinov >Priority: Major > Labels: collection, expiration, queue > > It's very useful collection wrapper for map with expiration - > PassiveExpiringMap. > Can you implement queue with expiration like already exist PassiveExpiringMap? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-735) Concurrent CircularFifoQueue
[
https://issues.apache.org/jira/browse/COLLECTIONS-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17000704#comment-17000704
]
Chen edited comment on COLLECTIONS-735 at 12/20/19 8:03 AM:
@David Mollitor, [~VarunVats9]:
I have created TransformedDeque, BlockingDeque, CircularDeque,
PredicatedDeque and SynchronizedDeque for deque interface(see
https://github.com/apache/commons-collections/pull/111), I think combine
CircularDeque and BlockingDeque will make a concurrent CircularFifoQueue. I
don't konw if there is a better way to complete it . It would be great if you
could review my PR and give some advice.
was (Author: guoping1):
David Mollitor, Varun Vats :
I have created TransformedDeque, BlockingDeque, CircularDeque,
PredicatedDeque and SynchronizedDeque for deque interface(see
https://github.com/apache/commons-collections/pull/111), I think combine
CircularDeque and BlockingDeque will make a concurrent CircularFifoQueue. I
don't konw if there is a better way to complete it . It would be great if you
could review my PR and give some advice.
> Concurrent CircularFifoQueue
>
>
> Key: COLLECTIONS-735
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-735
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Reporter: David Mollitor
>Priority: Major
>
> Create a {{CircularFifoQueue}} that is also a {{BlockingQueue}}.
> That is to say, if the queue is full, overwrite the oldest element. If the
> queue is empty, the reader blocks until a value becomes available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-735) Concurrent CircularFifoQueue
[
https://issues.apache.org/jira/browse/COLLECTIONS-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17000704#comment-17000704
]
Chen commented on COLLECTIONS-735:
--
David Mollitor, Varun Vats :
I have created TransformedDeque, BlockingDeque, CircularDeque,
PredicatedDeque and SynchronizedDeque for deque interface(see
https://github.com/apache/commons-collections/pull/111), I think combine
CircularDeque and BlockingDeque will make a concurrent CircularFifoQueue. I
don't konw if there is a better way to complete it . It would be great if you
could review my PR and give some advice.
> Concurrent CircularFifoQueue
>
>
> Key: COLLECTIONS-735
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-735
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Reporter: David Mollitor
>Priority: Major
>
> Create a {{CircularFifoQueue}} that is also a {{BlockingQueue}}.
> That is to say, if the queue is full, overwrite the oldest element. If the
> queue is empty, the reader blocks until a value becomes available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-735) Concurrent CircularFifoQueue
[
https://issues.apache.org/jira/browse/COLLECTIONS-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17000704#comment-17000704
]
Chen edited comment on COLLECTIONS-735 at 12/20/19 8:04 AM:
[~belugabehr], [~VarunVats9]:
I have created TransformedDeque, BlockingDeque, CircularDeque,
PredicatedDeque and SynchronizedDeque for deque interface(see
https://github.com/apache/commons-collections/pull/111), I think combine
CircularDeque and BlockingDeque will make a concurrent CircularFifoQueue. I
don't konw if there is a better way to complete it . It would be great if you
could review my PR and give some advice.
was (Author: guoping1):
@David Mollitor, [~VarunVats9]:
I have created TransformedDeque, BlockingDeque, CircularDeque,
PredicatedDeque and SynchronizedDeque for deque interface(see
https://github.com/apache/commons-collections/pull/111), I think combine
CircularDeque and BlockingDeque will make a concurrent CircularFifoQueue. I
don't konw if there is a better way to complete it . It would be great if you
could review my PR and give some advice.
> Concurrent CircularFifoQueue
>
>
> Key: COLLECTIONS-735
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-735
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Reporter: David Mollitor
>Priority: Major
>
> Create a {{CircularFifoQueue}} that is also a {{BlockingQueue}}.
> That is to say, if the queue is full, overwrite the oldest element. If the
> queue is empty, the reader blocks until a value becomes available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-732) Got an UnsupportedOperationException when using MultiValuedMap.MapIterator().setValue()
[
https://issues.apache.org/jira/browse/COLLECTIONS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17002582#comment-17002582
]
Chen commented on COLLECTIONS-732:
--
[~Guoping1]
> Got an UnsupportedOperationException when using
> MultiValuedMap.MapIterator().setValue()
> ---
>
> Key: COLLECTIONS-732
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-732
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Reporter: Chen
>Priority: Major
>
> copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
> {code:java}
> public void testSetValueMapIterator(){
> final ListValuedMap listMap = new
> ArrayListValuedHashMap<>();
> List listA = listMap.get("A");
> listA.addAll(0, Arrays.asList("W", "X", "F"));
> List listB = listMap.get("B");
> listB.addAll(0, Arrays.asList("Q", "Q", "L"));
> assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
> for(MapIterator iterator = listMap.mapIterator();
> iterator.hasNext(); ){
> iterator.next();
> String value = iterator.getValue();
> if(value == "F"){
> iterator.setValue("B");
> }
> }
> assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
> }
> {code}
> It throws an UnsupportedOperationException when altering
> mapIterator().setValue()。
> I found UnsupportedOperationException is thrown in the code of setValue。So，if
> setValue method is not supported，the Javadoc should comment it。
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (COLLECTIONS-732) Got an UnsupportedOperationException when using MultiValuedMap.MapIterator().setValue()
[
https://issues.apache.org/jira/browse/COLLECTIONS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chen updated COLLECTIONS-732:
-
Comment: was deleted
(was: [~Guoping1])
> Got an UnsupportedOperationException when using
> MultiValuedMap.MapIterator().setValue()
> ---
>
> Key: COLLECTIONS-732
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-732
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Reporter: Chen
>Priority: Major
>
> copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
> {code:java}
> public void testSetValueMapIterator(){
> final ListValuedMap listMap = new
> ArrayListValuedHashMap<>();
> List listA = listMap.get("A");
> listA.addAll(0, Arrays.asList("W", "X", "F"));
> List listB = listMap.get("B");
> listB.addAll(0, Arrays.asList("Q", "Q", "L"));
> assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
> for(MapIterator iterator = listMap.mapIterator();
> iterator.hasNext(); ){
> iterator.next();
> String value = iterator.getValue();
> if(value == "F"){
> iterator.setValue("B");
> }
> }
> assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
> }
> {code}
> It throws an UnsupportedOperationException when altering
> mapIterator().setValue()。
> I found UnsupportedOperationException is thrown in the code of setValue。So，if
> setValue method is not supported，the Javadoc should comment it。
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-732) Got an UnsupportedOperationException when using MultiValuedMap.MapIterator().setValue()
[
https://issues.apache.org/jira/browse/COLLECTIONS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17016466#comment-17016466
]
Chen commented on COLLECTIONS-732:
--
Hi, [~kinow]
So, ```setValue()``` method in ```mapIterator``` should be supported?
> Got an UnsupportedOperationException when using
> MultiValuedMap.MapIterator().setValue()
> ---
>
> Key: COLLECTIONS-732
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-732
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Reporter: Chen
>Priority: Major
>
> copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
> {code:java}
> public void testSetValueMapIterator(){
> final ListValuedMap listMap = new
> ArrayListValuedHashMap<>();
> List listA = listMap.get("A");
> listA.addAll(0, Arrays.asList("W", "X", "F"));
> List listB = listMap.get("B");
> listB.addAll(0, Arrays.asList("Q", "Q", "L"));
> assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
> for(MapIterator iterator = listMap.mapIterator();
> iterator.hasNext(); ){
> iterator.next();
> String value = iterator.getValue();
> if(value == "F"){
> iterator.setValue("B");
> }
> }
> assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
> }
> {code}
> It throws an UnsupportedOperationException when altering
> mapIterator().setValue()。
> I found UnsupportedOperationException is thrown in the code of setValue。So，if
> setValue method is not supported，the Javadoc should comment it。
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-732) Got an UnsupportedOperationException when using MultiValuedMap.MapIterator().setValue()
[
https://issues.apache.org/jira/browse/COLLECTIONS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17016466#comment-17016466
]
Chen edited comment on COLLECTIONS-732 at 1/16/20 2:44 AM:
---
Hi, [~kinow]
So,{color:#4C9AFF} setValue(){color} method in {color:#4C9AFF}mapIterator
{color}should be supported?
was (Author: guoping1):
Hi, [~kinow]
So, ```setValue()``` method in ```mapIterator``` should be supported?
> Got an UnsupportedOperationException when using
> MultiValuedMap.MapIterator().setValue()
> ---
>
> Key: COLLECTIONS-732
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-732
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Reporter: Chen
>Priority: Major
>
> copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
> {code:java}
> public void testSetValueMapIterator(){
> final ListValuedMap listMap = new
> ArrayListValuedHashMap<>();
> List listA = listMap.get("A");
> listA.addAll(0, Arrays.asList("W", "X", "F"));
> List listB = listMap.get("B");
> listB.addAll(0, Arrays.asList("Q", "Q", "L"));
> assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
> for(MapIterator iterator = listMap.mapIterator();
> iterator.hasNext(); ){
> iterator.next();
> String value = iterator.getValue();
> if(value == "F"){
> iterator.setValue("B");
> }
> }
> assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
> }
> {code}
> It throws an UnsupportedOperationException when altering
> mapIterator().setValue()。
> I found UnsupportedOperationException is thrown in the code of setValue。So，if
> setValue method is not supported，the Javadoc should comment it。
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CSV-93) Allow the handling of NULL values
[
https://issues.apache.org/jira/browse/CSV-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17035850#comment-17035850
]
Chen commented on CSV-93:
-
I think this issue is related with
[csv-253|https://issues.apache.org/jira/browse/CSV-253]
> Allow the handling of NULL values
> -
>
> Key: CSV-93
> URL: https://issues.apache.org/jira/browse/CSV-93
> Project: Commons CSV
> Issue Type: Improvement
> Components: Documentation, Parser, Printer
>Affects Versions: 1.0
>Reporter: Georg Tsakumagos
>Priority: Major
> Fix For: 1.0
>
> Attachments: CSV-93.diff, patch.txt
>
>
> h5. Requirement
> To use the CSV parser and printer for SQL Dumps it would be nice if they
> could handle *null* values.
> h5. Specification
> To distinguish between an *empty* or *null* value empty values always gets
> quoted to denote an empty string. The absence of an quote denotes a *null*
> value
> h5. Configuration
> To activate the behavior call the method _withNullObjectPatternEnabled_ of
> the _CSVFormat_ with parameter _true_.
> h5. Modifications
> See attached patch.
> h5. Example
> This example using as base the _DEFAULT_ _CSVFormat_ modified by the
> NullObjectPattern behavior.
> || Array-Data || CSV-Data ||
> | \{null,"","A"," "\}; |,"A",""," " |
> | \{"",null,"A"," "\} |"",,"A"," " |
> | \{"","A",null\} |"","A", |
> h5. NULL in DBMS proprietary CSV formats
> || Product || Strategy || Documentation / Link ||
> | PostgreSQL | If NULL should be preserved all non NULL values gets quoted |
> [PostgreSQL 8.1
> Manual|http://www.postgresql.org/docs/8.1/static/sql-copy.html] |
> | MySQL | NULL Values will be replaced by the letters NULL or escaped by \n |
> not found, verified with MySQL Workbench |
> | MS SQL | NULL values will be exported as empty strings (no quotes). Strings
> will be quoted if needed. Import can interpret them as null |
> [MSDN|http://msdn.microsoft.com/en-us//library/ms187887] |
> | Oracle | NULL Values will be replaced by the letters NULL |
> [Manual|http://docs.oracle.com/cd/B25329_01/doc/admin.102/b25107/impexp.htm] |
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CSV-195) Parser iterates over the last CSV Record twice.
[
https://issues.apache.org/jira/browse/CSV-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038854#comment-17038854
]
Chen commented on CSV-195:
--
it is same question with
[CSV-149|[https://issues.apache.org/jira/projects/CSV/issues/CSV-149?filter=allopenissues]]
> Parser iterates over the last CSV Record twice.
> ---
>
> Key: CSV-195
> URL: https://issues.apache.org/jira/browse/CSV-195
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
> Environment: Mac OS X 10.10.5
>Reporter: Rodolfo Duldulao
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: whitelist.csv
>
>
> {code:java}
> class CSVParserSpecification extends Specification {
>def "TEst CSVParser"() {
> setup:
> URL url = new URL("https://../csv_with_28_lines_header_plus_
> 27_records");
> BufferedReader reader = new BufferedReader(new
> InputStreamReader(url.openStream()));
> def CSVParser parser =
> CSVFormat.RFC4180.withFirstRecordAsHeader().withIgnoreEmptyLines().withTrim().parse(reader);
> when:
> def count = 0
> for (CSVRecord record: parser)
> { println("Processing " + parser.getCurrentLineNumber()) count++ }
> println(count);
> parser.close()
> then:
> count == 27
>}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CSV-195) Parser iterates over the last CSV Record twice.
[
https://issues.apache.org/jira/browse/CSV-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038854#comment-17038854
]
Chen edited comment on CSV-195 at 2/18/20 9:19 AM:
---
it is same question with
[CSV-149|[https://issues.apache.org/jira/projects/CSV/issues/CSV-149?filter=allopenissues]]
and the linenumber is count how many CRLF have been readed, may be when read
EOF shoud linenunber++ as well?
was (Author: guoping1):
it is same question with
[CSV-149|[https://issues.apache.org/jira/projects/CSV/issues/CSV-149?filter=allopenissues]]
> Parser iterates over the last CSV Record twice.
> ---
>
> Key: CSV-195
> URL: https://issues.apache.org/jira/browse/CSV-195
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
> Environment: Mac OS X 10.10.5
>Reporter: Rodolfo Duldulao
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: whitelist.csv
>
>
> {code:java}
> class CSVParserSpecification extends Specification {
>def "TEst CSVParser"() {
> setup:
> URL url = new URL("https://../csv_with_28_lines_header_plus_
> 27_records");
> BufferedReader reader = new BufferedReader(new
> InputStreamReader(url.openStream()));
> def CSVParser parser =
> CSVFormat.RFC4180.withFirstRecordAsHeader().withIgnoreEmptyLines().withTrim().parse(reader);
> when:
> def count = 0
> for (CSVRecord record: parser)
> { println("Processing " + parser.getCurrentLineNumber()) count++ }
> println(count);
> parser.close()
> then:
> count == 27
>}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CSV-149) Line number is not proper at EOF
[ https://issues.apache.org/jira/browse/CSV-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044045#comment-17044045 ] Chen commented on CSV-149: -- I have commit a pr at github [pr|[https://github.com/apache/commons-csv/pull/60]] , may somebody have review? > Line number is not proper at EOF > > > Key: CSV-149 > URL: https://issues.apache.org/jira/browse/CSV-149 > Project: Commons CSV > Issue Type: Bug > Components: Parser >Affects Versions: 1.1 > Environment: CSV 1.1, Java 1.6, Windows OS >Reporter: Kranthi >Priority: Major > Fix For: Patch Needed > > Attachments: csv-145-unit-test.diff > > > CSVParser.getCurrentLineNumber() is returning wrong line number (actual line > number - 1) when EOF file is reached without record delimiter (\r\n). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CSV-195) Parser iterates over the last CSV Record twice.
[
https://issues.apache.org/jira/browse/CSV-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044044#comment-17044044
]
Chen commented on CSV-195:
--
I have commit a pr at github
[pr|[https://github.com/apache/commons-csv/pull/60]] , may somebody have review?
> Parser iterates over the last CSV Record twice.
> ---
>
> Key: CSV-195
> URL: https://issues.apache.org/jira/browse/CSV-195
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
> Environment: Mac OS X 10.10.5
>Reporter: Rodolfo Duldulao
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: whitelist.csv
>
>
> {code:java}
> class CSVParserSpecification extends Specification {
>def "TEst CSVParser"() {
> setup:
> URL url = new URL("https://../csv_with_28_lines_header_plus_
> 27_records");
> BufferedReader reader = new BufferedReader(new
> InputStreamReader(url.openStream()));
> def CSVParser parser =
> CSVFormat.RFC4180.withFirstRecordAsHeader().withIgnoreEmptyLines().withTrim().parse(reader);
> when:
> def count = 0
> for (CSVRecord record: parser)
> { println("Processing " + parser.getCurrentLineNumber()) count++ }
> println(count);
> parser.close()
> then:
> count == 27
>}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CSV-253) Handle absent values in input (null)
[
https://issues.apache.org/jira/browse/CSV-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044155#comment-17044155
]
Chen commented on CSV-253:
--
It seems that many issues related wtih null and emptyValue , as I know
CSV-253,CSV-254,CSV-93,CSV-152.
May be even more.
> Handle absent values in input (null)
>
>
> Key: CSV-253
> URL: https://issues.apache.org/jira/browse/CSV-253
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Reporter: Lars Bruun-Hansen
>Priority: Major
> Attachments: 2019-10-30 20_31_39-Apache Commons CSV 1.8-SNAPSHOT
> API.png, Parser-setting-absentIsNull-Javadoc.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The parser must be able to handle absent values in input and translate that
> into {{null}} as required. I see several tickets on this matter in the
> history, but none seem to have addressed the issue, at least not for parsing.
> For this problem, I see a need to introduce a new term:
> Definition: _Absent value_ is when there are zero characters between field
> delimiters.
> Specifically the aim is to be able to parse the following:
> {noformat}
> "John",,"Doe"// 2nd element is absent
> ,"AA",123// 1st element is absent
> "John",90, // 3rd element is absent
> "",,90 // 2nd element is absent (1st element isn't)
> {noformat}
>
> See also CSV-93 which I think never addressed the issue, probably because the
> reporter was happy with having the issue fixed for CSV output, not for
> parsing.
> A PR is coming...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CSV-253) Handle absent values in input (null)
[
https://issues.apache.org/jira/browse/CSV-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044155#comment-17044155
]
Chen edited comment on CSV-253 at 2/25/20 6:41 AM:
---
It seems that many issues related wtih null and emptyValue , as I know
CSV-253,CSV-254,CSV-93,CSV-152.
May be even more.
Should we need a standard to process null and emptyValue?
was (Author: guoping1):
It seems that many issues related wtih null and emptyValue , as I know
CSV-253,CSV-254,CSV-93,CSV-152.
May be even more.
> Handle absent values in input (null)
>
>
> Key: CSV-253
> URL: https://issues.apache.org/jira/browse/CSV-253
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Reporter: Lars Bruun-Hansen
>Priority: Major
> Attachments: 2019-10-30 20_31_39-Apache Commons CSV 1.8-SNAPSHOT
> API.png, Parser-setting-absentIsNull-Javadoc.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The parser must be able to handle absent values in input and translate that
> into {{null}} as required. I see several tickets on this matter in the
> history, but none seem to have addressed the issue, at least not for parsing.
> For this problem, I see a need to introduce a new term:
> Definition: _Absent value_ is when there are zero characters between field
> delimiters.
> Specifically the aim is to be able to parse the following:
> {noformat}
> "John",,"Doe"// 2nd element is absent
> ,"AA",123// 1st element is absent
> "John",90, // 3rd element is absent
> "",,90 // 2nd element is absent (1st element isn't)
> {noformat}
>
> See also CSV-93 which I think never addressed the issue, probably because the
> reporter was happy with having the issue fixed for CSV output, not for
> parsing.
> A PR is coming...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CSV-253) Handle absent values in input (null)
[
https://issues.apache.org/jira/browse/CSV-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17053074#comment-17053074
]
Chen commented on CSV-253:
--
[~lbruun] looks goog(y)
> Handle absent values in input (null)
>
>
> Key: CSV-253
> URL: https://issues.apache.org/jira/browse/CSV-253
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Reporter: Lars Bruun-Hansen
>Priority: Major
> Attachments: 2019-10-30 20_31_39-Apache Commons CSV 1.8-SNAPSHOT
> API.png, Parser-setting-absentIsNull-Javadoc.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The parser must be able to handle absent values in input and translate that
> into {{null}} as required. I see several tickets on this matter in the
> history, but none seem to have addressed the issue, at least not for parsing.
> For this problem, I see a need to introduce a new term:
> Definition: _Absent value_ is when there are zero characters between field
> delimiters.
> Specifically the aim is to be able to parse the following:
> {noformat}
> "John",,"Doe"// 2nd element is absent
> ,"AA",123// 1st element is absent
> "John",90, // 3rd element is absent
> "",,90 // 2nd element is absent (1st element isn't)
> {noformat}
>
> See also CSV-93 which I think never addressed the issue, probably because the
> reporter was happy with having the issue fixed for CSV output, not for
> parsing.
> A PR is coming...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (CSV-253) Handle absent values in input (null)
[
https://issues.apache.org/jira/browse/CSV-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chen updated CSV-253:
-
Comment: was deleted
(was: [~lbruun] looks goog(y))
> Handle absent values in input (null)
>
>
> Key: CSV-253
> URL: https://issues.apache.org/jira/browse/CSV-253
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Reporter: Lars Bruun-Hansen
>Priority: Major
> Attachments: 2019-10-30 20_31_39-Apache Commons CSV 1.8-SNAPSHOT
> API.png, Parser-setting-absentIsNull-Javadoc.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The parser must be able to handle absent values in input and translate that
> into {{null}} as required. I see several tickets on this matter in the
> history, but none seem to have addressed the issue, at least not for parsing.
> For this problem, I see a need to introduce a new term:
> Definition: _Absent value_ is when there are zero characters between field
> delimiters.
> Specifically the aim is to be able to parse the following:
> {noformat}
> "John",,"Doe"// 2nd element is absent
> ,"AA",123// 1st element is absent
> "John",90, // 3rd element is absent
> "",,90 // 2nd element is absent (1st element isn't)
> {noformat}
>
> See also CSV-93 which I think never addressed the issue, probably because the
> reporter was happy with having the issue fixed for CSV output, not for
> parsing.
> A PR is coming...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CSV-257) Updating from 1.6 to 1.7 breaks
[
https://issues.apache.org/jira/browse/CSV-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17053102#comment-17053102
]
Chen commented on CSV-257:
--
I don't think that is a problem, after tracing the code in CSVParser.java
linenum 498 as below .The Parser does not think emptystring is a meaningful
header
{code:java}
//代码占位符
final boolean emptyHeader = header == null || header.trim().isEmpty();
if (emptyHeader && !this.format.getAllowMissingColumnNames()) {
throw new IllegalArgumentException(
"A header name is missing in " + Arrays.toString(headerRecord));
}
{code}
> Updating from 1.6 to 1.7 breaks
> ---
>
> Key: CSV-257
> URL: https://issues.apache.org/jira/browse/CSV-257
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.7
>Reporter: xia0c
>Priority: Major
>
> When I try to upgrade commons csv from 1.6 to the latest version 1.7. The
> following code breaks.
> {code:java}
> public class Demo {
> @Test
> public void TestCSV(){
> try {
> InputStream testInput = new
> ByteArrayInputStream(",".getBytes(StandardCharsets.UTF_8));
> Reader reader = new InputStreamReader(testInput);
> char character = ",".charAt(0);
> CSVFormat format =
> CSVFormat.RFC4180.withDelimiter(character).withFirstRecordAsHeader().withIgnoreSurroundingSpaces();
> CSVParser parser = new CSVParser(reader, format);
> } catch (Exception e) {
> System.out.println("!!!");
> assertEquals("java.lang.IllegalArgumentException: The
> header contains a duplicate name: \"\" in [, ]", e.toString());
> }
> }
> }
> {code}
> The test should pass, but it failed with error:
> {code:java}
> org.junit.ComparisonFailure: expected:<...lArgumentException: [The header
> contains a duplicate name: ""] in [, ]> but was:<...lArgumentException: [A
> header name is missing] in [, ]>
> at org.junit.Assert.assertEquals(Assert.java:115)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at Demo.TestCSV(Demo.java:31)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CSV-150) Escaping is not disableable
[
https://issues.apache.org/jira/browse/CSV-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17053916#comment-17053916
]
Chen commented on CSV-150:
--
Unicode with BOM will generate '\ufffe' , in normal case we can use Common IO
to filter the inpustream.
but in this case '\ufffe' comes out not the first bytes, so the problem is
should we survive from not clean data input ?
yet I think that using magic char to map null is not so good
> Escaping is not disableable
> ---
>
> Key: CSV-150
> URL: https://issues.apache.org/jira/browse/CSV-150
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.1
>Reporter: Georg Tsakumagos
>Priority: Major
> Fix For: Review
>
> Attachments: CSV-150.patch
>
>
> h6. Problem
> If escaping is disabled the Lexer maps the NULL Character to the magic char
> '\ufffe'. I currently hit this char randomly with data. This leads to a
> RuntimeException inside of
> org.apache.commons.csv.Lexer.parseEncapsulatedToken(Token) with the message
> "invalid char between encapsulated token and delimiter".
> h6. Solution
> Don't map the Character object and use it.
> {code:title=Lexer.java|borderStyle=solid}
> Lexer(final CSVFormat format, final ExtendedBufferedReader reader) {
> this.reader = reader;
> this.delimiter = format.getDelimiter();
> this.escape = format.getEscapeCharacter();
> .
> .
> .
> }
> boolean isEscape(final int ch) {
> return null != this.escape && escape.charValue() == ch;
> }
> {code}
> h6. Hint
> This pattern is used in other cases to. It seem to be a systematic error.
> This cases should be refactored also.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CSV-148) CSVFormat.ignoreSurroundingSpaces is ignored when printing
[
https://issues.apache.org/jira/browse/CSV-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17053939#comment-17053939
]
Chen commented on CSV-148:
--
just replace
{code:java}
.withIgnoreSurroundingSpaces(true)
{code}
to
{code:java}
.withTrim()
{code}
the testunit could past . so why dou we need a patch?
> CSVFormat.ignoreSurroundingSpaces is ignored when printing
> --
>
> Key: CSV-148
> URL: https://issues.apache.org/jira/browse/CSV-148
> Project: Commons CSV
> Issue Type: Bug
> Components: Printer
>Affects Versions: 1.1
> Environment: JDK 1.7
>Reporter: Piotr Ciruk
>Priority: Minor
> Fix For: Review
>
> Attachments: commons-csv_CSV-148.patch, commons-csv_CSV-148.patch
>
>
> It seems that {{CSVFormat}}'s property {{ignoreSurroundingSpaces}} is not
> taken into consideration while printing out values using {{CSVPrinter}}.
> Given:
> {code}
> System.out.println(
> CSVFormat.DEFAULT
> .withIgnoreSurroundingSpaces(true)
> .format("",
> " ",
> " Single space on the left",
> "Single space on the right ",
> " Single spaces on both sides ",
> " Multiple spaces on the left",
> "Multiple spaces on the right",
> " Multiple spaces on both sides ")
> );
> {code}
> Actual result:
> {code}
> ""," "," Single space on the left","Single space on the right "," Single
> spaces on both sides "," Multiple spaces on the left","Multiple spaces on
> the right"," Multiple spaces on both sides "
> {code}
> Expected result:
> {code}
> "","","Single space on the left","Single space on the right","Single spaces
> on both sides","Multiple spaces on the left","Multiple spaces on the
> right","Multiple spaces on both sides"
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
