[jira] [Commented] (CONFIGURATION-703) xml:space="preserve" does not handle blank strings properly
[
https://issues.apache.org/jira/browse/CONFIGURATION-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507225#comment-16507225
]
Pascal Essiembre commented on CONFIGURATION-703:
Sure, here you go:
{code:xml}
Pascal Essiembre
pascal.essiem...@norconex.com
Norconex Inc.
https://www.norconex.com
developer
-4
{code}
Thanks.
> xml:space="preserve" does not handle blank strings properly
> ---
>
> Key: CONFIGURATION-703
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-703
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Pascal Essiembre
>Priority: Major
> Fix For: 2.3
>
>
> When using XMLConfiguration 2, tags containing only white spaces are not
> handled properly when xml:space="preserve" is set. 'null' is returned
> instead of the actual spaces. To reproduce:
>
> {code:java}
> XMLConfiguration xml = new BasicConfigurationBuilder<>(
> XMLConfiguration.class).configure(
> new Parameters().xml()).getConfiguration();
> FileHandler fh = new FileHandler(xml);
> fh.load(new StringReader(""));
> System.out.println("TEST: '" + xml.getString("") + "'");
> // Outputs -> TEST: 'null'
> // Should be -> TEST: ''
> {code}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLI-284) Inconsistency in constraints for creating an instance of class Option using builder pattern or constructor
[
https://issues.apache.org/jira/browse/CLI-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507207#comment-16507207
]
ASF GitHub Bot commented on CLI-284:
Github user kinow commented on the issue:
https://github.com/apache/commons-cli/pull/25
Hi @sfuhrm thanks for the pull request. I had a look at the CLI-284 issue
in JIRA, and also checked out the pull request locally to take a look in
Eclipse.
I believe we have some tests failing due to this change. See the Travis-CI
build log, or try running `mvn clean test` locally. I got the following in my
environment:
```
Tests run: 410, Failures: 0, Errors: 55, Skipped: 54
```
The only other comment I have is about the duplicated code that we have now.
`Option`'s constructor checks for either `opt` or `longOpt` being present.
But so does `Option$Builder#build()`.
What about moving the
```java
if (opt == null && longOpt == null)
{
throw new IllegalArgumentException("Either opt or longOpt must be
specified");
}
```
check to `OptionValidator`? Maybe that way we avoid having the same if in
two places, and running the risk of someday changing one without changing the
other (though tests should catch it).
Thanks!
> Inconsistency in constraints for creating an instance of class Option using
> builder pattern or constructor
> --
>
> Key: CLI-284
> URL: https://issues.apache.org/jira/browse/CLI-284
> Project: Commons CLI
> Issue Type: Bug
>Reporter: Dilraj Singh
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: CLI284.patch
>
>
> Builder pattern for creating an instance of class *Option* ensures that at
> least one of the representation (short and long representation) for the
> option is not null. It throws an *IllegalArgumentException* in-case program
> tries to build an instance with both the representations as null. Consider
> the following code snippet for reference.
> {code:java}
> public static void main(String[] args) {
> Option.Builder builder = Option.builder();
> Option op = builder.build();
> }
> {code}
> This piece of code fails with the following exception
> {noformat}
> Exception in thread "main" java.lang.IllegalArgumentException: Either opt or
> longOpt must be specified
> {noformat}
> But if we try to create an instance of Option by calling its constructor, It
> allows the creation with both opt and longOpt for Option as null. Consider
> the following code snippet for reference
> {code:java}
> public static void main(String[] args) {
> Option op = new Option(null, null);
> System.out.format("Short Representation: %s\n" +
> "Long Representation: %s", op.getOpt(),
> op.getLongOpt());
> }
> {code}
> Output:
> {noformat}
> Short Representation: null
> Long Representation: null
> {noformat}
> Calling a method on an instance with both opt and longOpt as null will lead
> to undesired null pointer exception. For example, calling
> {code:java}
> op.getId() {code}
> will throw a null pointer exception, thus violating the method contract.
> So as to fix this we need to make sure that whenever a constructor is invoked
> it has a non-null argument value for at least one of the Option
> representation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLI-284) Inconsistency in constraints for creating an instance of class Option using builder pattern or constructor
[
https://issues.apache.org/jira/browse/CLI-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507206#comment-16507206
]
ASF GitHub Bot commented on CLI-284:
Github user kinow commented on the issue:
https://github.com/apache/commons-cli/pull/25
Hi @sfuhrm thanks for the pull request. I had a look at the CLI-284 issue
in JIRA, and also checked out the pull request locally to take a look in
Eclipse.
I believe we have some tests failing due to this change. See the Travis-CI
build log, or try running `mvn clean test` locally. I got the following in my
environment:
```
Tests run: 410, Failures: 0, Errors: 55, Skipped: 54
```
The only other comment I have is about the duplicated code that we have now.
`Option`'s constructor checks for either `opt` or `longOpt` being present.
But so does `Option$Builder#build()`.
What about moving the
```java
if (opt == null && longOpt == null)
{
throw new IllegalArgumentException("Either opt or longOpt must be
specified");
}
```
check to `OptionValidator`? Maybe that way we avoid having the same if in
two places, and running the risk of someday changing one without changing the
other (though tests should catch it).
Thanks!
> Inconsistency in constraints for creating an instance of class Option using
> builder pattern or constructor
> --
>
> Key: CLI-284
> URL: https://issues.apache.org/jira/browse/CLI-284
> Project: Commons CLI
> Issue Type: Bug
>Reporter: Dilraj Singh
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: CLI284.patch
>
>
> Builder pattern for creating an instance of class *Option* ensures that at
> least one of the representation (short and long representation) for the
> option is not null. It throws an *IllegalArgumentException* in-case program
> tries to build an instance with both the representations as null. Consider
> the following code snippet for reference.
> {code:java}
> public static void main(String[] args) {
> Option.Builder builder = Option.builder();
> Option op = builder.build();
> }
> {code}
> This piece of code fails with the following exception
> {noformat}
> Exception in thread "main" java.lang.IllegalArgumentException: Either opt or
> longOpt must be specified
> {noformat}
> But if we try to create an instance of Option by calling its constructor, It
> allows the creation with both opt and longOpt for Option as null. Consider
> the following code snippet for reference
> {code:java}
> public static void main(String[] args) {
> Option op = new Option(null, null);
> System.out.format("Short Representation: %s\n" +
> "Long Representation: %s", op.getOpt(),
> op.getLongOpt());
> }
> {code}
> Output:
> {noformat}
> Short Representation: null
> Long Representation: null
> {noformat}
> Calling a method on an instance with both opt and longOpt as null will lead
> to undesired null pointer exception. For example, calling
> {code:java}
> op.getId() {code}
> will throw a null pointer exception, thus violating the method contract.
> So as to fix this we need to make sure that whenever a constructor is invoked
> it has a non-null argument value for at least one of the Option
> representation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (COLLECTIONS-681) Add test for MultiSetUtils
[ https://issues.apache.org/jira/browse/COLLECTIONS-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved COLLECTIONS-681. Resolution: Fixed Fix Version/s: 4.2 Pull request merged! Thank you [~fury]! > 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] (COLLECTIONS-681) Add test for MultiSetUtils
[ https://issues.apache.org/jira/browse/COLLECTIONS-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507201#comment-16507201 ] ASF GitHub Bot commented on COLLECTIONS-681: Github user asfgit closed the pull request at: https://github.com/apache/commons-collections/pull/38 > 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] (COLLECTIONS-681) Add test for MultiSetUtils
[ https://issues.apache.org/jira/browse/COLLECTIONS-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507200#comment-16507200 ] ASF GitHub Bot commented on COLLECTIONS-681: Github user asfgit closed the pull request at: https://github.com/apache/commons-collections/pull/38 > 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] [Updated] (CLI-284) Inconsistency in constraints for creating an instance of class Option using builder pattern or constructor
[
https://issues.apache.org/jira/browse/CLI-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated CLI-284:
---
Assignee: Bruno P. Kinoshita
> Inconsistency in constraints for creating an instance of class Option using
> builder pattern or constructor
> --
>
> Key: CLI-284
> URL: https://issues.apache.org/jira/browse/CLI-284
> Project: Commons CLI
> Issue Type: Bug
>Reporter: Dilraj Singh
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: CLI284.patch
>
>
> Builder pattern for creating an instance of class *Option* ensures that at
> least one of the representation (short and long representation) for the
> option is not null. It throws an *IllegalArgumentException* in-case program
> tries to build an instance with both the representations as null. Consider
> the following code snippet for reference.
> {code:java}
> public static void main(String[] args) {
> Option.Builder builder = Option.builder();
> Option op = builder.build();
> }
> {code}
> This piece of code fails with the following exception
> {noformat}
> Exception in thread "main" java.lang.IllegalArgumentException: Either opt or
> longOpt must be specified
> {noformat}
> But if we try to create an instance of Option by calling its constructor, It
> allows the creation with both opt and longOpt for Option as null. Consider
> the following code snippet for reference
> {code:java}
> public static void main(String[] args) {
> Option op = new Option(null, null);
> System.out.format("Short Representation: %s\n" +
> "Long Representation: %s", op.getOpt(),
> op.getLongOpt());
> }
> {code}
> Output:
> {noformat}
> Short Representation: null
> Long Representation: null
> {noformat}
> Calling a method on an instance with both opt and longOpt as null will lead
> to undesired null pointer exception. For example, calling
> {code:java}
> op.getId() {code}
> will throw a null pointer exception, thus violating the method contract.
> So as to fix this we need to make sure that whenever a constructor is invoked
> it has a non-null argument value for at least one of the Option
> representation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (COLLECTIONS-681) Add test for MultiSetUtils
[ https://issues.apache.org/jira/browse/COLLECTIONS-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated COLLECTIONS-681: --- Assignee: Bruno P. Kinoshita > 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 > > MultiSetUtils has no tests. Add unit tests for the class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LANG-1339) Some classes depend on the java.desktop profile
[ https://issues.apache.org/jira/browse/LANG-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507185#comment-16507185 ] ASF GitHub Bot commented on LANG-1339: -- Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/275 Posted to the mailing list and will wait to see if there is any further feedback. Otherwise I will merge it in the next days. Thank you @jodastephen ! > Some classes depend on the java.desktop profile > --- > > Key: LANG-1339 > URL: https://issues.apache.org/jira/browse/LANG-1339 > Project: Commons Lang > Issue Type: Task >Reporter: Benedikt Ritter >Priority: Major > Labels: Java9 > Fix For: 3.8 > > > Commons Lang currently depends on java.desktop. This seems like an > unnecessary heavy dependency for a library like Commons Lang. We need to find > a way to fix this, without breaking bc. For more information see > https://lists.apache.org/thread.html/8db8ec4aa1bdeae3d471ca4f46a21dc7da1a4c6933e1810238b72283@%3Cdev.commons.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #275: LANG-1339: replace java.beans.PropertyListener by j...
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/275 Posted to the mailing list and will wait to see if there is any further feedback. Otherwise I will merge it in the next days. Thank you @jodastephen ! ---
[GitHub] commons-lang issue #275: [WIP] LANG-1339: replace java.beans.PropertyListene...
Github user jodastephen commented on the issue: https://github.com/apache/commons-lang/pull/275 Thanks @kinow , this seems like the right solution. Now the module-info can just use `require static` to avoid creating a full dependency on the awkward three classes and users have a practical alternative (either add the `java.desktop` dependency manually, or migrate to the replacement classes. ---
[jira] [Commented] (LANG-1339) Some classes depend on the java.desktop profile
[ https://issues.apache.org/jira/browse/LANG-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507151#comment-16507151 ] ASF GitHub Bot commented on LANG-1339: -- Github user jodastephen commented on the issue: https://github.com/apache/commons-lang/pull/275 Thanks @kinow , this seems like the right solution. Now the module-info can just use `require static` to avoid creating a full dependency on the awkward three classes and users have a practical alternative (either add the `java.desktop` dependency manually, or migrate to the replacement classes. > Some classes depend on the java.desktop profile > --- > > Key: LANG-1339 > URL: https://issues.apache.org/jira/browse/LANG-1339 > Project: Commons Lang > Issue Type: Task >Reporter: Benedikt Ritter >Priority: Major > Labels: Java9 > Fix For: 3.8 > > > Commons Lang currently depends on java.desktop. This seems like an > unnecessary heavy dependency for a library like Commons Lang. We need to find > a way to fix this, without breaking bc. For more information see > https://lists.apache.org/thread.html/8db8ec4aa1bdeae3d471ca4f46a21dc7da1a4c6933e1810238b72283@%3Cdev.commons.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-703) xml:space="preserve" does not handle blank strings properly
[
https://issues.apache.org/jira/browse/CONFIGURATION-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-703.
Resolution: Fixed
Fix Version/s: 2.3
The patch was applied (with minor tweaks) in SVN revision 1833251. Many thanks
again.
If you want to be listed in the contributors section of pom.xml, please send us
the data you want to have added.
> xml:space="preserve" does not handle blank strings properly
> ---
>
> Key: CONFIGURATION-703
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-703
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Pascal Essiembre
>Priority: Major
> Fix For: 2.3
>
>
> When using XMLConfiguration 2, tags containing only white spaces are not
> handled properly when xml:space="preserve" is set. 'null' is returned
> instead of the actual spaces. To reproduce:
>
> {code:java}
> XMLConfiguration xml = new BasicConfigurationBuilder<>(
> XMLConfiguration.class).configure(
> new Parameters().xml()).getConfiguration();
> FileHandler fh = new FileHandler(xml);
> fh.load(new StringReader(""));
> System.out.println("TEST: '" + xml.getString("") + "'");
> // Outputs -> TEST: 'null'
> // Should be -> TEST: ''
> {code}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-681) Add test for MultiSetUtils
[ https://issues.apache.org/jira/browse/COLLECTIONS-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507103#comment-16507103 ] ASF GitHub Bot commented on COLLECTIONS-681: Github user coveralls commented on the issue: https://github.com/apache/commons-collections/pull/38 [](https://coveralls.io/builds/17408068) Coverage increased (+0.07%) to 86.644% when pulling **d0fefc5b50aeb7acbad5fbc4b36266d7ed6a855d on sfuhrm:MultiSetUtilsTest** into **13ba1cc91ea441ab012fa4e9724fbca397f1b1cf on apache:master**. > 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 >Priority: Major > > MultiSetUtils has no tests. Add unit tests for the class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COLLECTIONS-681) Add test for MultiSetUtils
Stephan Fuhrmann created COLLECTIONS-681: Summary: 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 MultiSetUtils has no tests. Add unit tests for the class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-681) Add test for MultiSetUtils
[ https://issues.apache.org/jira/browse/COLLECTIONS-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507099#comment-16507099 ] ASF GitHub Bot commented on COLLECTIONS-681: GitHub user sfuhrm opened a pull request: https://github.com/apache/commons-collections/pull/38 COLLECTIONS-681: New unit test for MultiSetUtils A unit test for the MultiSetUtils. The MultiSetUtils had no tests at all, so this will improve the overall coverage. You can merge this pull request into a Git repository by running: $ git pull https://github.com/sfuhrm/commons-collections MultiSetUtilsTest Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-collections/pull/38.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 #38 commit d0fefc5b50aeb7acbad5fbc4b36266d7ed6a855d Author: Stephan Fuhrmann Date: 2018-06-09T18:11:59Z New unit test for MultiSetUtils > 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 >Priority: Major > > MultiSetUtils has no tests. Add unit tests for the class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-681) Add test for MultiSetUtils
[ https://issues.apache.org/jira/browse/COLLECTIONS-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507098#comment-16507098 ] ASF GitHub Bot commented on COLLECTIONS-681: GitHub user sfuhrm opened a pull request: https://github.com/apache/commons-collections/pull/38 COLLECTIONS-681: New unit test for MultiSetUtils A unit test for the MultiSetUtils. The MultiSetUtils had no tests at all, so this will improve the overall coverage. You can merge this pull request into a Git repository by running: $ git pull https://github.com/sfuhrm/commons-collections MultiSetUtilsTest Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-collections/pull/38.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 #38 commit d0fefc5b50aeb7acbad5fbc4b36266d7ed6a855d Author: Stephan Fuhrmann Date: 2018-06-09T18:11:59Z New unit test for MultiSetUtils > 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 >Priority: Major > > MultiSetUtils has no tests. Add unit tests for the class. -- 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=16507087#comment-16507087
]
ASF GitHub Bot commented on COLLECTIONS-673:
Github user coveralls commented on the issue:
https://github.com/apache/commons-collections/pull/37
[](https://coveralls.io/builds/17407790)
Coverage increased (+0.007%) to 86.582% when pulling
**faf27f611f4429c77a800124b5fb6f641f871c0f on sfuhrm:COLLECTIONS-673** into
**13ba1cc91ea441ab012fa4e9724fbca397f1b1cf on apache:master**.
> 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=16507085#comment-16507085
]
ASF GitHub Bot commented on COLLECTIONS-673:
GitHub user sfuhrm opened a pull request:
https://github.com/apache/commons-collections/pull/37
COLLECTIONS-673: Fix inspired by the Guava partition() implementation
A fix for the COLLECTIONS-673 bug and a unit test proving the fix for the
shown defect.
See https://issues.apache.org/jira/browse/COLLECTIONS-673
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/sfuhrm/commons-collections COLLECTIONS-673
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-collections/pull/37.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 #37
commit faf27f611f4429c77a800124b5fb6f641f871c0f
Author: Stephan Fuhrmann
Date: 2018-06-09T17:30:13Z
COLLECTIONS-673: Fix inspired by the Guava partition() implementation
> 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=16507084#comment-16507084
]
ASF GitHub Bot commented on COLLECTIONS-673:
GitHub user sfuhrm opened a pull request:
https://github.com/apache/commons-collections/pull/37
COLLECTIONS-673: Fix inspired by the Guava partition() implementation
A fix for the COLLECTIONS-673 bug and a unit test proving the fix for the
shown defect.
See https://issues.apache.org/jira/browse/COLLECTIONS-673
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/sfuhrm/commons-collections COLLECTIONS-673
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-collections/pull/37.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 #37
commit faf27f611f4429c77a800124b5fb6f641f871c0f
Author: Stephan Fuhrmann
Date: 2018-06-09T17:30:13Z
COLLECTIONS-673: Fix inspired by the Guava partition() implementation
> 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] [Closed] (POOL-344) Delete repeated call startEvictor
[ https://issues.apache.org/jira/browse/POOL-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed POOL-344. - Resolution: Fixed Fix Version/s: 2.6.0 In git master. > Delete repeated call startEvictor > - > > Key: POOL-344 > URL: https://issues.apache.org/jira/browse/POOL-344 > Project: Commons Pool > Issue Type: Improvement >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.6.0 > > > Delete repeated call startEvictor. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (POOL-344) Delete repeated call startEvictor
Gary Gregory created POOL-344: - Summary: Delete repeated call startEvictor Key: POOL-344 URL: https://issues.apache.org/jira/browse/POOL-344 Project: Commons Pool Issue Type: Improvement Reporter: Gary Gregory Assignee: Gary Gregory Delete repeated call startEvictor. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (DBCP-497) Deprecate use of PStmtKeyCPDS in favor of PStmtKey
[
https://issues.apache.org/jira/browse/DBCP-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed DBCP-497.
-
Resolution: Fixed
Fix Version/s: 2.4.0
> Deprecate use of PStmtKeyCPDS in favor of PStmtKey
> --
>
> Key: DBCP-497
> URL: https://issues.apache.org/jira/browse/DBCP-497
> Project: Commons DBCP
> Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.4.0
>
>
> Deprecate use of {{PStmtKeyCPDS}} in favor of {{PStmtKey}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (DBCP-497) Deprecate use of PStmtKeyCPDS in favor of PStmtKey
[
https://issues.apache.org/jira/browse/DBCP-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory reopened DBCP-497:
---
> Deprecate use of PStmtKeyCPDS in favor of PStmtKey
> --
>
> Key: DBCP-497
> URL: https://issues.apache.org/jira/browse/DBCP-497
> Project: Commons DBCP
> Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.4.0
>
>
> Deprecate use of {{PStmtKeyCPDS}} in favor of {{PStmtKey}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLI-258) PosixParser.parse continues to parse even after non-option parameter is appeared
[
https://issues.apache.org/jira/browse/CLI-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506952#comment-16506952
]
Stephan Fuhrmann commented on CLI-258:
--
PosixParser was deprecated:
{quote}@deprecated since 1.3, use the \{@link DefaultParser} instead
{quote}
> PosixParser.parse continues to parse even after non-option parameter is
> appeared
>
>
> Key: CLI-258
> URL: https://issues.apache.org/jira/browse/CLI-258
> Project: Commons CLI
> Issue Type: Bug
> Components: CLI-1.x
>Affects Versions: 1.3
>Reporter: Yasuko Komiyama
>Priority: Major
>
> If PosixParser.parse(Options options, String[] arguments, Properties
> properties, boolean stopAtNonOption) is called with stopAtNonOption = TRUE,
> once parse() finds any non-option parameter, it is supposed to stop parsing
> and treat all the rest of the parameters 'as is'. But when one or more than
> one options are appeared before the non-option parameter, the parser
> continues to parse the parameters even after the non-option parameter.
> If the non-option parameter is appeared before any options, the parser
> stops parsing (as expected).
> For example, when the option -x and -y are configured, the
> PosixParser.parse(options, "nonOption -xvalue1 -yvalue2", properties, TRUE)
> parses the arguments as 'nonOption, -xvalue1, -yvalue2". But if it is called
> with "-xvalue1 nonOption -yvalue2", then it parses as '-x, value1, nonOption,
> -y, value2". For the latter case the 3rd parameter "-yvalue2" should not be
> parsed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLI-284) Inconsistency in constraints for creating an instance of class Option using builder pattern or constructor
[
https://issues.apache.org/jira/browse/CLI-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506949#comment-16506949
]
ASF GitHub Bot commented on CLI-284:
GitHub user sfuhrm opened a pull request:
https://github.com/apache/commons-cli/pull/25
CLI-284: Fix inconsistent behaviour for short and long name == null
Fix for https://issues.apache.org/jira/browse/CLI-284
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/sfuhrm/commons-cli master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-cli/pull/25.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 #25
commit 4a2e95d01e39d89ffb2711f0b13f0020fef0d561
Author: Stephan Fuhrmann
Date: 2018-06-09T11:24:13Z
CLI-284: Fix inconsistent behaviour for short and long name == null
> Inconsistency in constraints for creating an instance of class Option using
> builder pattern or constructor
> --
>
> Key: CLI-284
> URL: https://issues.apache.org/jira/browse/CLI-284
> Project: Commons CLI
> Issue Type: Bug
>Reporter: Dilraj Singh
>Priority: Major
> Attachments: CLI284.patch
>
>
> Builder pattern for creating an instance of class *Option* ensures that at
> least one of the representation (short and long representation) for the
> option is not null. It throws an *IllegalArgumentException* in-case program
> tries to build an instance with both the representations as null. Consider
> the following code snippet for reference.
> {code:java}
> public static void main(String[] args) {
> Option.Builder builder = Option.builder();
> Option op = builder.build();
> }
> {code}
> This piece of code fails with the following exception
> {noformat}
> Exception in thread "main" java.lang.IllegalArgumentException: Either opt or
> longOpt must be specified
> {noformat}
> But if we try to create an instance of Option by calling its constructor, It
> allows the creation with both opt and longOpt for Option as null. Consider
> the following code snippet for reference
> {code:java}
> public static void main(String[] args) {
> Option op = new Option(null, null);
> System.out.format("Short Representation: %s\n" +
> "Long Representation: %s", op.getOpt(),
> op.getLongOpt());
> }
> {code}
> Output:
> {noformat}
> Short Representation: null
> Long Representation: null
> {noformat}
> Calling a method on an instance with both opt and longOpt as null will lead
> to undesired null pointer exception. For example, calling
> {code:java}
> op.getId() {code}
> will throw a null pointer exception, thus violating the method contract.
> So as to fix this we need to make sure that whenever a constructor is invoked
> it has a non-null argument value for at least one of the Option
> representation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLI-284) Inconsistency in constraints for creating an instance of class Option using builder pattern or constructor
[
https://issues.apache.org/jira/browse/CLI-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506950#comment-16506950
]
ASF GitHub Bot commented on CLI-284:
GitHub user sfuhrm opened a pull request:
https://github.com/apache/commons-cli/pull/25
CLI-284: Fix inconsistent behaviour for short and long name == null
Fix for https://issues.apache.org/jira/browse/CLI-284
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/sfuhrm/commons-cli master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-cli/pull/25.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 #25
commit 4a2e95d01e39d89ffb2711f0b13f0020fef0d561
Author: Stephan Fuhrmann
Date: 2018-06-09T11:24:13Z
CLI-284: Fix inconsistent behaviour for short and long name == null
> Inconsistency in constraints for creating an instance of class Option using
> builder pattern or constructor
> --
>
> Key: CLI-284
> URL: https://issues.apache.org/jira/browse/CLI-284
> Project: Commons CLI
> Issue Type: Bug
>Reporter: Dilraj Singh
>Priority: Major
> Attachments: CLI284.patch
>
>
> Builder pattern for creating an instance of class *Option* ensures that at
> least one of the representation (short and long representation) for the
> option is not null. It throws an *IllegalArgumentException* in-case program
> tries to build an instance with both the representations as null. Consider
> the following code snippet for reference.
> {code:java}
> public static void main(String[] args) {
> Option.Builder builder = Option.builder();
> Option op = builder.build();
> }
> {code}
> This piece of code fails with the following exception
> {noformat}
> Exception in thread "main" java.lang.IllegalArgumentException: Either opt or
> longOpt must be specified
> {noformat}
> But if we try to create an instance of Option by calling its constructor, It
> allows the creation with both opt and longOpt for Option as null. Consider
> the following code snippet for reference
> {code:java}
> public static void main(String[] args) {
> Option op = new Option(null, null);
> System.out.format("Short Representation: %s\n" +
> "Long Representation: %s", op.getOpt(),
> op.getLongOpt());
> }
> {code}
> Output:
> {noformat}
> Short Representation: null
> Long Representation: null
> {noformat}
> Calling a method on an instance with both opt and longOpt as null will lead
> to undesired null pointer exception. For example, calling
> {code:java}
> op.getId() {code}
> will throw a null pointer exception, thus violating the method contract.
> So as to fix this we need to make sure that whenever a constructor is invoked
> it has a non-null argument value for at least one of the Option
> representation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLI-284) Inconsistency in constraints for creating an instance of class Option using builder pattern or constructor
[
https://issues.apache.org/jira/browse/CLI-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506939#comment-16506939
]
Stephan Fuhrmann commented on CLI-284:
--
I think your point is right.
I'm proposing the attached patch for the project.
> Inconsistency in constraints for creating an instance of class Option using
> builder pattern or constructor
> --
>
> Key: CLI-284
> URL: https://issues.apache.org/jira/browse/CLI-284
> Project: Commons CLI
> Issue Type: Bug
>Reporter: Dilraj Singh
>Priority: Major
> Attachments: CLI284.patch
>
>
> Builder pattern for creating an instance of class *Option* ensures that at
> least one of the representation (short and long representation) for the
> option is not null. It throws an *IllegalArgumentException* in-case program
> tries to build an instance with both the representations as null. Consider
> the following code snippet for reference.
> {code:java}
> public static void main(String[] args) {
> Option.Builder builder = Option.builder();
> Option op = builder.build();
> }
> {code}
> This piece of code fails with the following exception
> {noformat}
> Exception in thread "main" java.lang.IllegalArgumentException: Either opt or
> longOpt must be specified
> {noformat}
> But if we try to create an instance of Option by calling its constructor, It
> allows the creation with both opt and longOpt for Option as null. Consider
> the following code snippet for reference
> {code:java}
> public static void main(String[] args) {
> Option op = new Option(null, null);
> System.out.format("Short Representation: %s\n" +
> "Long Representation: %s", op.getOpt(),
> op.getLongOpt());
> }
> {code}
> Output:
> {noformat}
> Short Representation: null
> Long Representation: null
> {noformat}
> Calling a method on an instance with both opt and longOpt as null will lead
> to undesired null pointer exception. For example, calling
> {code:java}
> op.getId() {code}
> will throw a null pointer exception, thus violating the method contract.
> So as to fix this we need to make sure that whenever a constructor is invoked
> it has a non-null argument value for at least one of the Option
> representation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CLI-284) Inconsistency in constraints for creating an instance of class Option using builder pattern or constructor
[
https://issues.apache.org/jira/browse/CLI-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Fuhrmann updated CLI-284:
-
Attachment: CLI284.patch
> Inconsistency in constraints for creating an instance of class Option using
> builder pattern or constructor
> --
>
> Key: CLI-284
> URL: https://issues.apache.org/jira/browse/CLI-284
> Project: Commons CLI
> Issue Type: Bug
>Reporter: Dilraj Singh
>Priority: Major
> Attachments: CLI284.patch
>
>
> Builder pattern for creating an instance of class *Option* ensures that at
> least one of the representation (short and long representation) for the
> option is not null. It throws an *IllegalArgumentException* in-case program
> tries to build an instance with both the representations as null. Consider
> the following code snippet for reference.
> {code:java}
> public static void main(String[] args) {
> Option.Builder builder = Option.builder();
> Option op = builder.build();
> }
> {code}
> This piece of code fails with the following exception
> {noformat}
> Exception in thread "main" java.lang.IllegalArgumentException: Either opt or
> longOpt must be specified
> {noformat}
> But if we try to create an instance of Option by calling its constructor, It
> allows the creation with both opt and longOpt for Option as null. Consider
> the following code snippet for reference
> {code:java}
> public static void main(String[] args) {
> Option op = new Option(null, null);
> System.out.format("Short Representation: %s\n" +
> "Long Representation: %s", op.getOpt(),
> op.getLongOpt());
> }
> {code}
> Output:
> {noformat}
> Short Representation: null
> Long Representation: null
> {noformat}
> Calling a method on an instance with both opt and longOpt as null will lead
> to undesired null pointer exception. For example, calling
> {code:java}
> op.getId() {code}
> will throw a null pointer exception, thus violating the method contract.
> So as to fix this we need to make sure that whenever a constructor is invoked
> it has a non-null argument value for at least one of the Option
> representation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1339) Some classes depend on the java.desktop profile
[ https://issues.apache.org/jira/browse/LANG-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506908#comment-16506908 ] ASF GitHub Bot commented on LANG-1339: -- Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/275 [](https://coveralls.io/builds/17405129) Coverage increased (+0.03%) to 95.271% when pulling **e089e4c294292f8255701429ec9b22057025a1a8 on kinow:LANG-1339** into **70be8e5148a2f616399c3205c169df600400833c on apache:master**. > Some classes depend on the java.desktop profile > --- > > Key: LANG-1339 > URL: https://issues.apache.org/jira/browse/LANG-1339 > Project: Commons Lang > Issue Type: Task >Reporter: Benedikt Ritter >Priority: Major > Labels: Java9 > Fix For: 3.8 > > > Commons Lang currently depends on java.desktop. This seems like an > unnecessary heavy dependency for a library like Commons Lang. We need to find > a way to fix this, without breaking bc. For more information see > https://lists.apache.org/thread.html/8db8ec4aa1bdeae3d471ca4f46a21dc7da1a4c6933e1810238b72283@%3Cdev.commons.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #275: [WIP] LANG-1339: replace java.beans.PropertyListene...
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/275 [](https://coveralls.io/builds/17405129) Coverage increased (+0.03%) to 95.271% when pulling **e089e4c294292f8255701429ec9b22057025a1a8 on kinow:LANG-1339** into **70be8e5148a2f616399c3205c169df600400833c on apache:master**. ---
[jira] [Commented] (LANG-1339) Some classes depend on the java.desktop profile
[ https://issues.apache.org/jira/browse/LANG-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506906#comment-16506906 ] ASF GitHub Bot commented on LANG-1339: -- Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/275 @jodastephen done. Kept the existing classes, but added new ones where the only modification is replacing `java.beans` by `java.util` equivalent classes. Existing classes were annotated with `@deprecated` with a comment pointing to the new class. WDTY? I'd like to sort it out as soon as possible to sort out the issue with dependencies & Java 9 in lang. Thanks! Bruno ps: old code was removed from commit line. Moved instead to a branch at https://github.com/kinow/commons-lang/tree/LANG-1339-old, just in case we need to compare it or someone wants to see what it was before > Some classes depend on the java.desktop profile > --- > > Key: LANG-1339 > URL: https://issues.apache.org/jira/browse/LANG-1339 > Project: Commons Lang > Issue Type: Task >Reporter: Benedikt Ritter >Priority: Major > Labels: Java9 > Fix For: 3.8 > > > Commons Lang currently depends on java.desktop. This seems like an > unnecessary heavy dependency for a library like Commons Lang. We need to find > a way to fix this, without breaking bc. For more information see > https://lists.apache.org/thread.html/8db8ec4aa1bdeae3d471ca4f46a21dc7da1a4c6933e1810238b72283@%3Cdev.commons.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #275: [WIP] LANG-1339: replace java.beans.PropertyListene...
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/275 @jodastephen done. Kept the existing classes, but added new ones where the only modification is replacing `java.beans` by `java.util` equivalent classes. Existing classes were annotated with `@deprecated` with a comment pointing to the new class. WDTY? I'd like to sort it out as soon as possible to sort out the issue with dependencies & Java 9 in lang. Thanks! Bruno ps: old code was removed from commit line. Moved instead to a branch at https://github.com/kinow/commons-lang/tree/LANG-1339-old, just in case we need to compare it or someone wants to see what it was before ---
[jira] [Commented] (IO-554) FileUtils.copyToFile(InputStream source, File destination) closes input stream
[
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506882#comment-16506882
]
Bruno P. Kinoshita commented on IO-554:
---
TL;DR;
* *2.5 did not close the stream*
* *2.6 closed the stream after the introduction of try-with-resources*
* *This issue is about the changed behaviour, with a pull request to revert it
back to 2.5 behaviour*
Recapitulating;
I believe the *copyToFile* method was released with Release 2.5 – 2016-04-22,
added in this commit from IO-381 from May 2013
[https://github.com/apache/commons-io/commit/ee2f71d9fd2ce253f53de137950fa90087b9f565]
The code from the 2.5 released tag reads:
{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 {
final FileOutputStream output = openOutputStream(destination);
try {
IOUtils.copy(source, output);
output.close(); // don't swallow close Exception if copy completes
normally
} finally {
IOUtils.closeQuietly(output);
}
}
{code}
NB the Javadocs states "*The \{@code source} stream is left open*". I had a
look at the code, and tested in Eclipse, and it is indeed left open.
But on this commit from May 2016, released later with Release 2.6 –
2017-10-15, we added try-with-resources, which changed the behaviour of the
code.
The code from IO-505 from the 2.6 released tag_**_ reads:
{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}
NB the Javadocs states "*The \{@code source} stream is left open*". But the
try-with-resources closes the in/source input stream. I think this change in
the behaviour was not intentional.
The pull request for this issue is proposing to revert what was added in 2.6. I
would not use commons-io-2.6 `copyToFile`, as I would normally handle the
stream myself, or use the other method that already closed the stream before.
[~tmortagne],
>I agree that behavior should not change but that's actually an argument for a
>bugfix release as fast as possible, not to keep a regression.
+1
In a similar case, Commons Pool 2.4.3 kept binary compatibility but changed the
way the code worked when iterating stack traces (see POOL-320), which caused an
issue and prevented us from using this version in Commons DBCP. Instead of
keeping the method and adding a new one, or updating documentation, we reverted
the change in 2.5.0 (see POOL-335).
In my opinion we should revert the regression added in 2.6, with [~mmariotti]
's pull request suggested, which also includes a unit test to prevent the
regression from happening again.
Cheers
Bruno
(**) There is a tag commons-io-2.5, but no commons-io-2.6, only RC1, RC2, and
commons-io-2.6-RC3.
>
