[jira] [Commented] (MATH-1404) Test failure which occur with LC_ALL=en_US.UTF8, but not with LC_ALL=de_DE.UTF-8
[ https://issues.apache.org/jira/browse/MATH-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509251#comment-16509251 ] Karl Richter commented on MATH-1404: The issue no longer occurs (tested with the compilation error fix). > Test failure which occur with LC_ALL=en_US.UTF8, but not with > LC_ALL=de_DE.UTF-8 > > > Key: MATH-1404 > URL: https://issues.apache.org/jira/browse/MATH-1404 > Project: Commons Math > Issue Type: Bug >Reporter: Karl Richter >Priority: Major > > Specifying `LC_ALL=en_US.UTF-8` causes test failures like > `RandomUtilsDataGeneratorJDKSecureRandomTest>RandomUtilsDataGeneratorAbstractTest.testNextLongNegativeRange:99->RandomUtilsDataGeneratorAbstractTest.checkNextLongUniform:130 > Chisquare test failed p-value = 0.0082266579945659 chisquare statistic = > 25.3040006.` which don't seem to occur with `LC_ALL=de_DE.UTF-8`, see > https://travis-ci.org/krichter722/commons-math/jobs/205896548 for details -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LANG-1369) Formatted and Paramaterized Exception Classes
[
https://issues.apache.org/jira/browse/LANG-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509568#comment-16509568
]
BELUGA BEHR commented on LANG-1369:
---
Any thoughts on this? :)
> Formatted and Paramaterized Exception Classes
> -
>
> Key: LANG-1369
> URL: https://issues.apache.org/jira/browse/LANG-1369
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.exception.*
>Affects Versions: 3.7
>Reporter: BELUGA BEHR
>Priority: Major
> Attachments: LANG-1369.1.patch
>
>
> Add two new Exception classes:
> # FormattedException
> # ParameterizedException
> Both classes provide different mechanisms for creating error messages instead
> of using straight string concatenation that can look sloppy and introduces a
> lot of {{StringBuilder}} instances into the underlying byte code.
> FormattedException uses Java's {{java.lang.String#format}} method for
> producing the Exception's detailed message. ParameterizedException uses
> Log4j's implementation of the SLF4J parameterization implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-685) IterableUtils has public constructor
[ https://issues.apache.org/jira/browse/COLLECTIONS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509227#comment-16509227 ] ASF GitHub Bot commented on COLLECTIONS-685: GitHub user sfuhrm opened a pull request: https://github.com/apache/commons-collections/pull/40 COLLECTIONS-685: IterableUtils has public constructor Constructor for Utils class was not private. This was obviously not intended as all other Utils classes have private constructors. You can merge this pull request into a Git repository by running: $ git pull https://github.com/sfuhrm/commons-collections COLLECTIONS-685 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-collections/pull/40.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #40 commit 49bc94faccddc2f81ce8af1db2bce8ccbede82d9 Author: Stephan Fuhrmann Date: 2018-06-12T06:02:06Z Constructor for Utils class was not private. This was obviously not intended as all other Utils classes have private constructors. > IterableUtils has public constructor > > > Key: COLLECTIONS-685 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-685 > Project: Commons Collections > Issue Type: Bug > Components: Collection >Reporter: Stephan Fuhrmann >Priority: Trivial > > IterableUtils has public constructor. All other Utils classes have their > constructor made private to prohibit instantiation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-685) IterableUtils has public constructor
[ https://issues.apache.org/jira/browse/COLLECTIONS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509226#comment-16509226 ] ASF GitHub Bot commented on COLLECTIONS-685: GitHub user sfuhrm opened a pull request: https://github.com/apache/commons-collections/pull/40 COLLECTIONS-685: IterableUtils has public constructor Constructor for Utils class was not private. This was obviously not intended as all other Utils classes have private constructors. You can merge this pull request into a Git repository by running: $ git pull https://github.com/sfuhrm/commons-collections COLLECTIONS-685 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-collections/pull/40.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #40 commit 49bc94faccddc2f81ce8af1db2bce8ccbede82d9 Author: Stephan Fuhrmann Date: 2018-06-12T06:02:06Z Constructor for Utils class was not private. This was obviously not intended as all other Utils classes have private constructors. > IterableUtils has public constructor > > > Key: COLLECTIONS-685 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-685 > Project: Commons Collections > Issue Type: Bug > Components: Collection >Reporter: Stephan Fuhrmann >Priority: Trivial > > IterableUtils has public constructor. All other Utils classes have their > constructor made private to prohibit instantiation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COLLECTIONS-685) IterableUtils has public constructor
Stephan Fuhrmann created COLLECTIONS-685: Summary: IterableUtils has public constructor Key: COLLECTIONS-685 URL: https://issues.apache.org/jira/browse/COLLECTIONS-685 Project: Commons Collections Issue Type: Bug Components: Collection Reporter: Stephan Fuhrmann IterableUtils has public constructor. All other Utils classes have their constructor made private to prohibit instantiation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-685) IterableUtils has public constructor
[ https://issues.apache.org/jira/browse/COLLECTIONS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509230#comment-16509230 ] ASF GitHub Bot commented on COLLECTIONS-685: Github user sfuhrm commented on the issue: https://github.com/apache/commons-collections/pull/40 BTW, TravisCI is right, technically this is an API change, but I suggest that all API uses are neither useful nor make sense. > IterableUtils has public constructor > > > Key: COLLECTIONS-685 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-685 > Project: Commons Collections > Issue Type: Bug > Components: Collection >Reporter: Stephan Fuhrmann >Priority: Trivial > > IterableUtils has public constructor. All other Utils classes have their > constructor made private to prohibit instantiation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COMPRESS-455) Cannot open certain APK file (Unexpected record signature)
Hai Zhang created COMPRESS-455:
--
Summary: Cannot open certain APK file (Unexpected record signature)
Key: COMPRESS-455
URL: https://issues.apache.org/jira/browse/COMPRESS-455
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.17
Environment: Android 8.1.0
Reporter: Hai Zhang
I'm developing a file manager for Android and noticed that
ZipArchiveInputStream throws an exception for certain APK files (but not all) I
have at hand:
{noformat}
06-12 23:01:03.043 26960-4050/me.zhanghai.android.materialfilemanager
W/System.err: java.util.zip.ZipException: Unexpected record signature: 0X621
06-12 23:01:03.044 26960-4050/me.zhanghai.android.materialfilemanager
W/System.err: at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:258)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:406)
at
me.zhanghai.android.materialfilemanager.filesystem.Archive.readEntries(Archive.java:79)
at
me.zhanghai.android.materialfilemanager.filesystem.Archive.read(Archive.java:36)
at
me.zhanghai.android.materialfilemanager.filesystem.ArchiveFile.loadFileList(ArchiveFile.java:112)
at
me.zhanghai.android.materialfilemanager.filelist.FileLiveData$1.doInBackground(FileLiveData.java:32)
at
me.zhanghai.android.materialfilemanager.filelist.FileLiveData$1.doInBackground(FileLiveData.java:28)
at android.os.AsyncTask$2.call(AsyncTask.java:333)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:245)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764){noformat}
However, these APKs installs fine, and can be viewed by the system Files app
(by changing extension to zip) and some other opensource file managers built
upon java.util.zip.
Some links to APKs I found with this problem:
1.
[https://github.com/paphonb/PixelLauncherModV5/releases/download/5.3_23/Pixel.2.Launcher.modded.5.3.build.23.apk]
2. [https://github.com/Yink/Amadeus/releases/download/0.9.6-alpha.5/amadeus.apk]
My code for reading the APK archive entries:
{code:java}
private static void readEntries(InputStream inputStream, List
entries)
throws ArchiveException, IOException {
try (ArchiveInputStream archiveInputStream =
sArchiveStreamFactory.createArchiveInputStream(
new BufferedInputStream(inputStream))) {
while (true) {
ArchiveEntry entry = archiveInputStream.getNextEntry();
if (entry == null) {
break;
}
entries.add(entry);
}
}
}
{code}
Also note that if I catch the exception while keeping the list of already-read
entries, it seems that (almost) all entries have been read.
I wonder how this can be fixed, or if this is because those files have some
kind of weird format, how can I possibly work around this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-455) Cannot open certain APK file (Unexpected record signature)
[
https://issues.apache.org/jira/browse/COMPRESS-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509784#comment-16509784
]
Stefan Bodewig commented on COMPRESS-455:
-
The signature consisting of only two bytes looks strange (I'd expect the usual
"PK" bytes if this simply was some kind of unsupported feature inside of a
regular archive. Have you tried using {{ZipFile}} rather than
{{ZipArchiveInputStream}}? This has the benefit of being able to read the
central directory and doesn't have to scan the archive sequentially performing
pattern matching on suspect header signatures.
> Cannot open certain APK file (Unexpected record signature)
> --
>
> Key: COMPRESS-455
> URL: https://issues.apache.org/jira/browse/COMPRESS-455
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.17
> Environment: Android 8.1.0
>Reporter: Hai Zhang
>Priority: Major
>
> I'm developing a file manager for Android and noticed that
> ZipArchiveInputStream throws an exception for certain APK files (but not all)
> I have at hand:
>
> {noformat}
> 06-12 23:01:03.043 26960-4050/me.zhanghai.android.materialfilemanager
> W/System.err: java.util.zip.ZipException: Unexpected record signature: 0X621
> 06-12 23:01:03.044 26960-4050/me.zhanghai.android.materialfilemanager
> W/System.err: at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:258)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:406)
> at
> me.zhanghai.android.materialfilemanager.filesystem.Archive.readEntries(Archive.java:79)
> at
> me.zhanghai.android.materialfilemanager.filesystem.Archive.read(Archive.java:36)
> at
> me.zhanghai.android.materialfilemanager.filesystem.ArchiveFile.loadFileList(ArchiveFile.java:112)
> at
> me.zhanghai.android.materialfilemanager.filelist.FileLiveData$1.doInBackground(FileLiveData.java:32)
> at
> me.zhanghai.android.materialfilemanager.filelist.FileLiveData$1.doInBackground(FileLiveData.java:28)
> at android.os.AsyncTask$2.call(AsyncTask.java:333)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:245)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
> at java.lang.Thread.run(Thread.java:764){noformat}
>
> However, these APKs installs fine, and can be viewed by the system Files app
> (by changing extension to zip) and some other opensource file managers built
> upon java.util.zip.
> Some links to APKs I found with this problem:
> 1.
> [https://github.com/paphonb/PixelLauncherModV5/releases/download/5.3_23/Pixel.2.Launcher.modded.5.3.build.23.apk]
>
> 2.
> [https://github.com/Yink/Amadeus/releases/download/0.9.6-alpha.5/amadeus.apk]
> My code for reading the APK archive entries:
>
>
> {code:java}
> private static void readEntries(InputStream inputStream, List
> entries)
> throws ArchiveException, IOException {
> try (ArchiveInputStream archiveInputStream =
> sArchiveStreamFactory.createArchiveInputStream(
> new BufferedInputStream(inputStream))) {
> while (true) {
> ArchiveEntry entry = archiveInputStream.getNextEntry();
> if (entry == null) {
> break;
> }
> entries.add(entry);
> }
> }
> }
> {code}
> Also note that if I catch the exception while keeping the list of
> already-read entries, it seems that (almost) all entries have been read.
> I wonder how this can be fixed, or if this is because those files have some
> kind of weird format, how can I possibly work around this?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-685) IterableUtils has public constructor
[ https://issues.apache.org/jira/browse/COLLECTIONS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510263#comment-16510263 ] ASF GitHub Bot commented on COLLECTIONS-685: Github user sfuhrm closed the pull request at: https://github.com/apache/commons-collections/pull/40 > IterableUtils has public constructor > > > Key: COLLECTIONS-685 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-685 > Project: Commons Collections > Issue Type: Bug > Components: Collection >Reporter: Stephan Fuhrmann >Priority: Trivial > Fix For: 5.0 > > > IterableUtils has public constructor. All other Utils classes have their > constructor made private to prohibit instantiation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-685) IterableUtils has public constructor
[ https://issues.apache.org/jira/browse/COLLECTIONS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510264#comment-16510264 ] ASF GitHub Bot commented on COLLECTIONS-685: Github user sfuhrm closed the pull request at: https://github.com/apache/commons-collections/pull/40 > IterableUtils has public constructor > > > Key: COLLECTIONS-685 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-685 > Project: Commons Collections > Issue Type: Bug > Components: Collection >Reporter: Stephan Fuhrmann >Priority: Trivial > Fix For: 5.0 > > > IterableUtils has public constructor. All other Utils classes have their > constructor made private to prohibit instantiation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-685) IterableUtils has public constructor
[ https://issues.apache.org/jira/browse/COLLECTIONS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510262#comment-16510262 ] ASF GitHub Bot commented on COLLECTIONS-685: Github user sfuhrm commented on the issue: https://github.com/apache/commons-collections/pull/40 Closing because of breaking the API. May be interesting for commons-cli 5.0. > IterableUtils has public constructor > > > Key: COLLECTIONS-685 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-685 > Project: Commons Collections > Issue Type: Bug > Components: Collection >Reporter: Stephan Fuhrmann >Priority: Trivial > Fix For: 5.0 > > > IterableUtils has public constructor. All other Utils classes have their > constructor made private to prohibit instantiation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MATH-1464) convex optimization with constraints, barrier method
Erik Erlandson created MATH-1464: Summary: convex optimization with constraints, barrier method Key: MATH-1464 URL: https://issues.apache.org/jira/browse/MATH-1464 Project: Commons Math Issue Type: New Feature Reporter: Erik Erlandson Commons math supports SimplexOptimizer for linear programming. I created a somewhat similar package for convex optimization with constraints, which is here: [https://github.com/erikerlandson/gibbous] I designed it to work in the style of commons-math optimizers, so I thought I would propose it for inclusion with commons math optimization, to see if there is any community interest. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (COLLECTIONS-684) Flat3Map: Some test cases going more into the details
[ https://issues.apache.org/jira/browse/COLLECTIONS-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved COLLECTIONS-684. -- Resolution: Fixed Fix Version/s: 4.2 Patch applied, thank you! Please verify and close. > Flat3Map: Some test cases going more into the details > - > > Key: COLLECTIONS-684 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-684 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Reporter: Stephan Fuhrmann >Priority: Minor > Fix For: 4.2 > > > Flat3Map contains some long conditional sequences mixed with switch/case > blocks. > The unit test coverage for some methods was really low. > Add more unit tests to ensure that everything is all right. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IO-554) FileUtils.copyToFile(InputStream source, File destination) should not close input stream
[
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved IO-554.
-
Resolution: Fixed
Patch applied to git master. Please verify and close.
> FileUtils.copyToFile(InputStream source, File destination) should not close
> input stream
>
>
> Key: IO-554
> URL: https://issues.apache.org/jira/browse/IO-554
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Michele Mariotti
>Assignee: Bruno P. Kinoshita
>Priority: Blocker
> Labels: regression
> Fix For: 2.7
>
>
> In 2.6 this method is closing the input stream, while the javadoc states the
> opposite.
> The correct behavior is to leave the stream open, as stated in the javadoc.
> I assigned a high priority because this incorrect behavior breaks existing
> code, especially when used in combination with ZipInputStream.
> {code:java}
> /**
> * Copies bytes from an {@link InputStream} source to a file
> * destination. The directories up to destination
> * will be created if they don't already exist. destination
> * will be overwritten if it already exists.
> * The {@code source} stream is left open, e.g. for use with {@link
> java.util.zip.ZipInputStream ZipInputStream}.
> * See {@link #copyInputStreamToFile(InputStream, File)} for a method that
> closes the input stream.
> *
> * @param source the InputStream to copy bytes from, must
> not be {@code null}
> * @param destination the non-directory File to write bytes to
> *(possibly overwriting), must not be {@code null}
> * @throws IOException if destination is a directory
> * @throws IOException if destination cannot be written
> * @throws IOException if destination needs creating but can't be
> * @throws IOException if an IO error occurs during copying
> * @since 2.5
> */
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (InputStream in = source;
>OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(in, out);
> }
> }
> {code}
> instead it should be:
> {code:java}
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(source, out);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (POOL-343) CommonsPool2TargetSource release target giving error "Returned object not currently part of this pool"
[
https://issues.apache.org/jira/browse/POOL-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed POOL-343.
-
Resolution: Invalid
Closing per user's comment.
> CommonsPool2TargetSource release target giving error "Returned object not
> currently part of this pool"
> --
>
> Key: POOL-343
> URL: https://issues.apache.org/jira/browse/POOL-343
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.2, 2.4.1, 2.5.0
>Reporter: Shakun Ahuja
>Priority: Blocker
> Attachments: Beans.xml, GenericLifeCycleProcessor.java,
> PaymentInstructionActivationSchedulingExecutor.java
>
>
> After changing spring version to 5 with commons-pool
> 2.5,CommonsPool2TargetSource release target giving error as below
>
> {{ java.lang.IllegalStateException: Returned object not currently part of
> this pool at
> org.apache.commons.pool2.impl.GenericObjectPool.returnObject(GenericObjectPool.java:537)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (COLLECTIONS-685) IterableUtils has public constructor
[ https://issues.apache.org/jira/browse/COLLECTIONS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Fuhrmann updated COLLECTIONS-685: - Fix Version/s: 5.0 > IterableUtils has public constructor > > > Key: COLLECTIONS-685 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-685 > Project: Commons Collections > Issue Type: Bug > Components: Collection >Reporter: Stephan Fuhrmann >Priority: Trivial > Fix For: 5.0 > > > IterableUtils has public constructor. All other Utils classes have their > constructor made private to prohibit instantiation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IO-554) FileUtils.copyToFile(InputStream source, File destination) should not close input stream
[
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated IO-554:
Summary: FileUtils.copyToFile(InputStream source, File destination) should
not close input stream (was: FileUtils.copyToFile(InputStream source, File
destination) closes input stream)
> FileUtils.copyToFile(InputStream source, File destination) should not close
> input stream
>
>
> Key: IO-554
> URL: https://issues.apache.org/jira/browse/IO-554
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Michele Mariotti
>Assignee: Bruno P. Kinoshita
>Priority: Blocker
> Labels: regression
> Fix For: 2.7
>
>
> In 2.6 this method is closing the input stream, while the javadoc states the
> opposite.
> The correct behavior is to leave the stream open, as stated in the javadoc.
> I assigned a high priority because this incorrect behavior breaks existing
> code, especially when used in combination with ZipInputStream.
> {code:java}
> /**
> * Copies bytes from an {@link InputStream} source to a file
> * destination. The directories up to destination
> * will be created if they don't already exist. destination
> * will be overwritten if it already exists.
> * The {@code source} stream is left open, e.g. for use with {@link
> java.util.zip.ZipInputStream ZipInputStream}.
> * See {@link #copyInputStreamToFile(InputStream, File)} for a method that
> closes the input stream.
> *
> * @param source the InputStream to copy bytes from, must
> not be {@code null}
> * @param destination the non-directory File to write bytes to
> *(possibly overwriting), must not be {@code null}
> * @throws IOException if destination is a directory
> * @throws IOException if destination cannot be written
> * @throws IOException if destination needs creating but can't be
> * @throws IOException if an IO error occurs during copying
> * @since 2.5
> */
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (InputStream in = source;
>OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(in, out);
> }
> }
> {code}
> instead it should be:
> {code:java}
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(source, out);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (COLLECTIONS-673) ListUtils.partition potential integer overflow
[
https://issues.apache.org/jira/browse/COLLECTIONS-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved COLLECTIONS-673.
--
Resolution: Fixed
Fix Version/s: 4.2
Thank you for your patch, please verify and close.
> ListUtils.partition potential integer overflow
> --
>
> Key: COLLECTIONS-673
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-673
> Project: Commons Collections
> Issue Type: Bug
> Components: List
>Affects Versions: 4.1
>Reporter: John Mark
>Priority: Major
> Fix For: 4.2
>
>
> When calling {{ListUtils.partition()}} with a large size and large list, it
> is possible that an integer overflow will occur in the {{size()}} method that
> causes incorrect behavior. This will occur when using a size that, when added
> to list.size() will be larger than {{Integer.MAX_VALUE}}
> Current version of Guava's {{Lists.partition()}} handle this correctly, so
> perhaps the code for {{ListUtils.partition()}} needs to be updated based on
> the latest Guava code.
> A simple illustration of this:
> {code}
> List aList = Arrays.asList("1", "2", "3", "4", "5");
> List> partitioned = ListUtils.partition(aList,
> Integer.MAX_VALUE);
> System.out.println("Number of partitions: " + partitioned.size());
> for(List l : partitioned) {
> System.out.println(l);
> }
> {code}
> The above code works correctly when using Guava's {{Lists.partition()}}
> instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-673) ListUtils.partition potential integer overflow
[
https://issues.apache.org/jira/browse/COLLECTIONS-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510251#comment-16510251
]
ASF GitHub Bot commented on COLLECTIONS-673:
Github user asfgit closed the pull request at:
https://github.com/apache/commons-collections/pull/37
> ListUtils.partition potential integer overflow
> --
>
> Key: COLLECTIONS-673
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-673
> Project: Commons Collections
> Issue Type: Bug
> Components: List
>Affects Versions: 4.1
>Reporter: John Mark
>Priority: Major
>
> When calling {{ListUtils.partition()}} with a large size and large list, it
> is possible that an integer overflow will occur in the {{size()}} method that
> causes incorrect behavior. This will occur when using a size that, when added
> to list.size() will be larger than {{Integer.MAX_VALUE}}
> Current version of Guava's {{Lists.partition()}} handle this correctly, so
> perhaps the code for {{ListUtils.partition()}} needs to be updated based on
> the latest Guava code.
> A simple illustration of this:
> {code}
> List aList = Arrays.asList("1", "2", "3", "4", "5");
> List> partitioned = ListUtils.partition(aList,
> Integer.MAX_VALUE);
> System.out.println("Number of partitions: " + partitioned.size());
> for(List l : partitioned) {
> System.out.println(l);
> }
> {code}
> The above code works correctly when using Guava's {{Lists.partition()}}
> instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-673) ListUtils.partition potential integer overflow
[
https://issues.apache.org/jira/browse/COLLECTIONS-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510252#comment-16510252
]
ASF GitHub Bot commented on COLLECTIONS-673:
Github user asfgit closed the pull request at:
https://github.com/apache/commons-collections/pull/37
> ListUtils.partition potential integer overflow
> --
>
> Key: COLLECTIONS-673
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-673
> Project: Commons Collections
> Issue Type: Bug
> Components: List
>Affects Versions: 4.1
>Reporter: John Mark
>Priority: Major
>
> When calling {{ListUtils.partition()}} with a large size and large list, it
> is possible that an integer overflow will occur in the {{size()}} method that
> causes incorrect behavior. This will occur when using a size that, when added
> to list.size() will be larger than {{Integer.MAX_VALUE}}
> Current version of Guava's {{Lists.partition()}} handle this correctly, so
> perhaps the code for {{ListUtils.partition()}} needs to be updated based on
> the latest Guava code.
> A simple illustration of this:
> {code}
> List aList = Arrays.asList("1", "2", "3", "4", "5");
> List> partitioned = ListUtils.partition(aList,
> Integer.MAX_VALUE);
> System.out.println("Number of partitions: " + partitioned.size());
> for(List l : partitioned) {
> System.out.println(l);
> }
> {code}
> The above code works correctly when using Guava's {{Lists.partition()}}
> instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-684) Flat3Map: Some test cases going more into the details
[ https://issues.apache.org/jira/browse/COLLECTIONS-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510232#comment-16510232 ] ASF GitHub Bot commented on COLLECTIONS-684: Github user asfgit closed the pull request at: https://github.com/apache/commons-collections/pull/39 > Flat3Map: Some test cases going more into the details > - > > Key: COLLECTIONS-684 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-684 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Reporter: Stephan Fuhrmann >Priority: Minor > > Flat3Map contains some long conditional sequences mixed with switch/case > blocks. > The unit test coverage for some methods was really low. > Add more unit tests to ensure that everything is all right. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-684) Flat3Map: Some test cases going more into the details
[ https://issues.apache.org/jira/browse/COLLECTIONS-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510231#comment-16510231 ] ASF GitHub Bot commented on COLLECTIONS-684: Github user asfgit closed the pull request at: https://github.com/apache/commons-collections/pull/39 > Flat3Map: Some test cases going more into the details > - > > Key: COLLECTIONS-684 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-684 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Reporter: Stephan Fuhrmann >Priority: Minor > > Flat3Map contains some long conditional sequences mixed with switch/case > blocks. > The unit test coverage for some methods was really low. > Add more unit tests to ensure that everything is all right. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (COLLECTIONS-681) Add test for MultiSetUtils
[ https://issues.apache.org/jira/browse/COLLECTIONS-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Fuhrmann closed COLLECTIONS-681. Thanks for reviewing + merging, [~kinow]! > Add test for MultiSetUtils > -- > > Key: COLLECTIONS-681 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-681 > Project: Commons Collections > Issue Type: Improvement > Environment: https://coveralls.io/github/apache/commons-collections >Reporter: Stephan Fuhrmann >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 4.2 > > > MultiSetUtils has no tests. Add unit tests for the class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LANG-1369) Formatted and Paramaterized Exception Classes
[
https://issues.apache.org/jira/browse/LANG-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510067#comment-16510067
]
Gary Gregory commented on LANG-1369:
IMO, these are not helpful or good design because they subclass Exception
directly, so your code effectively ends up with "throws Exception" all over, a
bad smell usually. What you care about is the ease of formatting a message for
a specific _kind of_ exception. You must keep is the exception already in use,
like an {{IOException}} for example.
At work, I've introduced factory classes like {{IOExceptionFactory}} which
contain static methods like {{format(String, Object...)}}. This is OK for us
since there are usually are a smallish set of exceptions to throw with like
{{SQLException}}, a few {{Illegal*}} exceptions, and so on.
The generic alternative is:
{code:java}
public class ExceptionFactory {
public static T format(Class clazz, String format,
Object... args)
throws NoSuchMethodException, IllegalAccessException,
InvocationTargetException, InstantiationException {
return ConstructorUtils.invokeExactConstructor(clazz,
String.format(format, args));
}
}
{code}
But that is super lame due to the laundry list of checked exceptions, so you
could do instead:
{code:java}
public class ExceptionFactory {
public static T format(Class clazz, String format,
Object... args) {
final String message = String.format(format, args);
try {
return ConstructorUtils.invokeExactConstructor(clazz, message);
} catch (NoSuchMethodException | IllegalAccessException |
InvocationTargetException
| InstantiationException e) {
throw new IllegalArgumentException(
String.format("Caught %s while building exception class %s
for message %s", e, clazz, message), e);
}
}
}
{code}
Which is not as nasty but you are still using reflection which some folks might
not like, YMMV.
> Formatted and Paramaterized Exception Classes
> -
>
> Key: LANG-1369
> URL: https://issues.apache.org/jira/browse/LANG-1369
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.exception.*
>Affects Versions: 3.7
>Reporter: BELUGA BEHR
>Priority: Major
> Attachments: LANG-1369.1.patch
>
>
> Add two new Exception classes:
> # FormattedException
> # ParameterizedException
> Both classes provide different mechanisms for creating error messages instead
> of using straight string concatenation that can look sloppy and introduces a
> lot of {{StringBuilder}} instances into the underlying byte code.
> FormattedException uses Java's {{java.lang.String#format}} method for
> producing the Exception's detailed message. ParameterizedException uses
> Log4j's implementation of the SLF4J parameterization implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-685) IterableUtils has public constructor
[ https://issues.apache.org/jira/browse/COLLECTIONS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510261#comment-16510261 ] Stephan Fuhrmann commented on COLLECTIONS-685: -- [~garydgregory] thanks for your review! I undestand your view of the situation. I'll close the PR so no one needs to bother about this. This ticket can stay open as a reminder. > IterableUtils has public constructor > > > Key: COLLECTIONS-685 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-685 > Project: Commons Collections > Issue Type: Bug > Components: Collection >Reporter: Stephan Fuhrmann >Priority: Trivial > Fix For: 5.0 > > > IterableUtils has public constructor. All other Utils classes have their > constructor made private to prohibit instantiation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (COLLECTIONS-680) CollectionUtilsTest test for collect is broken
[ https://issues.apache.org/jira/browse/COLLECTIONS-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved COLLECTIONS-680. -- Resolution: Fixed Travis looks green ATM. Please review and close or comment. > CollectionUtilsTest test for collect is broken > -- > > Key: COLLECTIONS-680 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-680 > Project: Commons Collections > Issue Type: Bug > Components: Collection >Reporter: Konstantinos Angelopoulos >Priority: Major > > Cannot resolve method ConnectionUtils.collect in line 1289. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (COLLECTIONS-684) Flat3Map: Some test cases going more into the details
[ https://issues.apache.org/jira/browse/COLLECTIONS-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Fuhrmann closed COLLECTIONS-684. [~garydgregory] Thanks for reviewing + accepting! > Flat3Map: Some test cases going more into the details > - > > Key: COLLECTIONS-684 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-684 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Reporter: Stephan Fuhrmann >Priority: Minor > Fix For: 4.2 > > > Flat3Map contains some long conditional sequences mixed with switch/case > blocks. > The unit test coverage for some methods was really low. > Add more unit tests to ensure that everything is all right. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (COLLECTIONS-682) README.md contains unresolved template references
[
https://issues.apache.org/jira/browse/COLLECTIONS-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Fuhrmann closed COLLECTIONS-682.
Thanks for fixing so fast!
> README.md contains unresolved template references
> -
>
> Key: COLLECTIONS-682
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-682
> Project: Commons Collections
> Issue Type: Bug
> Environment:
> https://github.com/apache/commons-collections/blob/master/README.md
>Reporter: Stephan Fuhrmann
>Priority: Trivial
> Fix For: 4.2
>
> Attachments: readme-2018-06-11.png
>
>
> The README.md file contains an unresolved reference to
> {{${project.description}}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IO-554) FileUtils.copyToFile(InputStream source, File destination) should not close input stream
[
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510287#comment-16510287
]
ASF GitHub Bot commented on IO-554:
---
Github user asfgit closed the pull request at:
https://github.com/apache/commons-io/pull/49
> FileUtils.copyToFile(InputStream source, File destination) should not close
> input stream
>
>
> Key: IO-554
> URL: https://issues.apache.org/jira/browse/IO-554
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Michele Mariotti
>Assignee: Bruno P. Kinoshita
>Priority: Blocker
> Labels: regression
> Fix For: 2.7
>
>
> In 2.6 this method is closing the input stream, while the javadoc states the
> opposite.
> The correct behavior is to leave the stream open, as stated in the javadoc.
> I assigned a high priority because this incorrect behavior breaks existing
> code, especially when used in combination with ZipInputStream.
> {code:java}
> /**
> * Copies bytes from an {@link InputStream} source to a file
> * destination. The directories up to destination
> * will be created if they don't already exist. destination
> * will be overwritten if it already exists.
> * The {@code source} stream is left open, e.g. for use with {@link
> java.util.zip.ZipInputStream ZipInputStream}.
> * See {@link #copyInputStreamToFile(InputStream, File)} for a method that
> closes the input stream.
> *
> * @param source the InputStream to copy bytes from, must
> not be {@code null}
> * @param destination the non-directory File to write bytes to
> *(possibly overwriting), must not be {@code null}
> * @throws IOException if destination is a directory
> * @throws IOException if destination cannot be written
> * @throws IOException if destination needs creating but can't be
> * @throws IOException if an IO error occurs during copying
> * @since 2.5
> */
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (InputStream in = source;
>OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(in, out);
> }
> }
> {code}
> instead it should be:
> {code:java}
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(source, out);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (MATH-1463) Exception thrown by "IntegerSequence.Incrementor"
[
https://issues.apache.org/jira/browse/MATH-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved MATH-1463.
--
Resolution: Fixed
Commit 00a0c6cb866b01c0d48debae0faf884038279144 ("master" branch).
> Exception thrown by "IntegerSequence.Incrementor"
> -
>
> Key: MATH-1463
> URL: https://issues.apache.org/jira/browse/MATH-1463
> Project: Commons Math
> Issue Type: Bug
>Reporter: Gilles
>Assignee: Gilles
>Priority: Major
> Fix For: 4.0
>
>
> As {{IntegerSequence.Incrementor}} _implements_ {{java.util.Iterator}}, its
> {{next()}} method should abide by the interface's contract, i.e. throw
> {{java.util.NoSuchElementException}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-685) IterableUtils has public constructor
[ https://issues.apache.org/jira/browse/COLLECTIONS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509946#comment-16509946 ] Gary Gregory commented on COLLECTIONS-685: -- You cannot make a public API private without breaking binary compatiblity, so this is a no go in 4.x but would be OK for 5.0. > IterableUtils has public constructor > > > Key: COLLECTIONS-685 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-685 > Project: Commons Collections > Issue Type: Bug > Components: Collection >Reporter: Stephan Fuhrmann >Priority: Trivial > > IterableUtils has public constructor. All other Utils classes have their > constructor made private to prohibit instantiation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MATH-1463) Exception thrown by "IntegerSequence.Incrementor"
Gilles created MATH-1463:
Summary: Exception thrown by "IntegerSequence.Incrementor"
Key: MATH-1463
URL: https://issues.apache.org/jira/browse/MATH-1463
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Assignee: Gilles
Fix For: 4.0
As {{IntegerSequence.Incrementor}} _implements_ {{java.util.Iterator}}, its
{{next()}} method should abide by the interface's contract, i.e. throw
{{java.util.NoSuchElementException}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
