[GitHub] commons-lang issue #305: Remove unnecessary testing comments

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/305
  

[![Coverage 
Status](https://coveralls.io/builds/14043222/badge)](https://coveralls.io/builds/14043222)

Coverage remained the same at 95.164% when pulling 
**c163de74ae7686a8f661d00ddcd7f85272ee7f9a on hquan:master** into 
**425d8085cfcaab5a78bf0632f9ae77b7e9127cf8 on apache:master**.



---

[GitHub] commons-lang pull request #305: Remove unnecessary testing comments

[hquan]

GitHub user hquan opened a pull request:

https://github.com/apache/commons-lang/pull/305

Remove unnecessary testing comments



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/hquan/commons-lang master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/305.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 #305


commit c163de74ae7686a8f661d00ddcd7f85272ee7f9a
Author: Haoliang Quan 
Date:   2017-11-05T05:04:24Z

Remove unnecessary testing comments




---

[jira] [Updated] (IO-554) FileUtils.copyToFile(InputStream source, File destination) closes input stream

[Bruno P. Kinoshita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated IO-554:
--
Assignee: Bruno P. Kinoshita

> FileUtils.copyToFile(InputStream source, File destination) closes 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
(v6.4.14#64029)

[jira] [Commented] (IO-554) FileUtils.copyToFile(InputStream source, File destination) closes input stream

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239364#comment-16239364
 ] 

Bruno P. Kinoshita commented on IO-554:
---

Nice catch [~mmariotti]

Would you like to submit a pull request with this change? If not, let me know 
and I'll quickly prepare a pull request and credit you.

Thanks
Bruno

> FileUtils.copyToFile(InputStream source, File destination) closes 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
>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
(v6.4.14#64029)

[jira] [Commented] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239363#comment-16239363
 ] 

Bruno P. Kinoshita commented on COLLECTIONS-663:


I believe the Javadocs from asMap from MultiValuedMap indicate it works for as 
a view for a state in the collection. If you have to alter the map or the 
values collection, I'd try first using the mapIterator() method from the 
MultiValuedMap. It returns a custom iterator.

The following altered code works for me:

{code:java}
public void testAlteringCollection() {
MultiValuedMap multiMap = new 
HashSetValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(2, 20);
Iterator it = multiMap.mapIterator();
for (Iterator iterator = multiMap.mapIterator(); 
iterator.hasNext();) {
Integer i = iterator.next();
iterator.remove(); // only the innerCollection is altered
}
}
{code}

Does it help? Bruno

> Unexpected ConcurrentModificationException when altering Collection of a 
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
>  Issue Type: Bug
>Reporter: Christophe Schmaltz
>Priority: Trivial
>
> Testcase:
> {code}@Test
>   public void test() {
>   MultiValuedMap multiMap = new 
> HashSetValuedHashMap<>();
>   multiMap.put(1, 10);
>   multiMap.put(2, 20);
>   for (Collection innerCollection : 
> multiMap.asMap().values()) {
>   for (Iterator iterator = 
> innerCollection.iterator(); iterator.hasNext();) {
>   Integer i = iterator.next();
>   iterator.remove(); // only the innerCollection 
> is altered
>   }
>   // innerCollection.add(6); // adding stuff back should 
> also work...
>   }
>   }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the 
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is 
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on 
> the iterator if the outer map and called {{containerIterator.remove()}} 
> instead.
> *Note:* this solution would again present issues if the user tries to add new 
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without 
> debugging the code. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap

[Bruno P. Kinoshita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno P. Kinoshita updated COLLECTIONS-663:
---
Assignee: Bruno P. Kinoshita

> Unexpected ConcurrentModificationException when altering Collection of a 
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
>  Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
>   public void test() {
>   MultiValuedMap multiMap = new 
> HashSetValuedHashMap<>();
>   multiMap.put(1, 10);
>   multiMap.put(2, 20);
>   for (Collection innerCollection : 
> multiMap.asMap().values()) {
>   for (Iterator iterator = 
> innerCollection.iterator(); iterator.hasNext();) {
>   Integer i = iterator.next();
>   iterator.remove(); // only the innerCollection 
> is altered
>   }
>   // innerCollection.add(6); // adding stuff back should 
> also work...
>   }
>   }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the 
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is 
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on 
> the iterator if the outer map and called {{containerIterator.remove()}} 
> instead.
> *Note:* this solution would again present issues if the user tries to add new 
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without 
> debugging the code. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LANG-1339) Some classes depend on the java.desktop profile

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239358#comment-16239358
 ] 

ASF GitHub Bot commented on LANG-1339:
--

Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/275
  
>My suggestion would be to add two new classes with the fixed code 
(different class names), and deprecated the old classes. That way there is no 
need to have commons-lang v4.

Thought a bit about that after seeing the vote for [lang] 3.7. In any way, 
the current implementation will be removed only in 4.x, and we will have to 
include the require static for Java 9 module.

So right now I am thinking about not marking the class or fields as 
deprecated, nor adding another class with a different name. Just keep this PR 
and the ticket open. Then mark the ticket as FixVersion 4.0, use the require 
static trick for the module-info.java for Java 9.

Does that sound like a good plan?


> 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
>  Labels: Java9
> Fix For: 3.7
>
>
> 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
(v6.4.14#64029)

[GitHub] commons-lang issue #275: [WIP] LANG-1339: replace java.beans.PropertyListene...

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/275
  
>My suggestion would be to add two new classes with the fixed code 
(different class names), and deprecated the old classes. That way there is no 
need to have commons-lang v4.

Thought a bit about that after seeing the vote for [lang] 3.7. In any way, 
the current implementation will be removed only in 4.x, and we will have to 
include the require static for Java 9 module.

So right now I am thinking about not marking the class or fields as 
deprecated, nor adding another class with a different name. Just keep this PR 
and the ticket open. Then mark the ticket as FixVersion 4.0, use the require 
static trick for the module-info.java for Java 9.

Does that sound like a good plan?


---

[jira] [Updated] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap

[Christophe Schmaltz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christophe Schmaltz updated COLLECTIONS-663:

Description: 
Testcase:
{code}  @Test
public void test() {
MultiValuedMap multiMap = new 
HashSetValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(2, 20);
for (Collection innerCollection : 
multiMap.asMap().values()) {
for (Iterator iterator = 
innerCollection.iterator(); iterator.hasNext();) {
Integer i = iterator.next();
iterator.remove(); // only the innerCollection 
is altered
}
// innerCollection.add(6); // adding stuff back should 
also work...
}
}{code}
This test unexpectedly throws a ConcurrentModificationException.
The issue is that when calling {{iterator.remove()}} the 
{{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is empty 
and calls {{AbstractMultiValuedMap.this.remove(key);}}.

It may be better if the iterator of the inner collection had a reference on the 
iterator if the outer map and called {{containerIterator.remove()}} instead.
*Note:* this solution would again present issues if the user tries to add new 
elements in this now empty collection (which was removed from the parent).


In the current state, it is quite unclear why an exception is thrown, without 
debugging the code. 


  was:
Testcase:
{code}  @Test
public void test() {
MultiValuedMap multiMap = new 
HashSetValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(2, 20);
for (Collection innerCollection : 
multiMap.asMap().values()) {
for (Iterator iterator = 
innerCollection.iterator(); iterator.hasNext();) {
Integer i = iterator.next();
iterator.remove(); // only the innerCollection 
is altered
}
}
}{code}
This test unexpectedly throws a ConcurrentModificationException.
The issue is that when calling {{iterator.remove()}} the 
{{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is empty 
and calls {{AbstractMultiValuedMap.this.remove(key);}}.

It may be better if the iterator of the inner collection had a reference on the 
iterator if the outer map and called {{containerIterator.remove()}} instead.
*Note:* this solution would again present issues if the user tries to add new 
elements in this now empty collection (which was removed from the parent).


In the current state, it is quite unclear why an exception is thrown, without 
debugging the code. 



> Unexpected ConcurrentModificationException when altering Collection of a 
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
>  Issue Type: Bug
>Reporter: Christophe Schmaltz
>
> Testcase:
> {code}@Test
>   public void test() {
>   MultiValuedMap multiMap = new 
> HashSetValuedHashMap<>();
>   multiMap.put(1, 10);
>   multiMap.put(2, 20);
>   for (Collection innerCollection : 
> multiMap.asMap().values()) {
>   for (Iterator iterator = 
> innerCollection.iterator(); iterator.hasNext();) {
>   Integer i = iterator.next();
>   iterator.remove(); // only the innerCollection 
> is altered
>   }
>   // innerCollection.add(6); // adding stuff back should 
> also work...
>   }
>   }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the 
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is 
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on 
> the iterator if the outer map and called {{containerIterator.remove()}} 
> instead.
> *Note:* this solution would again present issues if the user tries to add new 
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without 
> debugging the code. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap

[Christophe Schmaltz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christophe Schmaltz updated COLLECTIONS-663:

Description: 
Testcase:
{code}  @Test
public void test() {
MultiValuedMap multiMap = new 
HashSetValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(2, 20);
for (Collection innerCollection : 
multiMap.asMap().values()) {
for (Iterator iterator = 
innerCollection.iterator(); iterator.hasNext();) {
Integer i = iterator.next();
iterator.remove(); // only the innerCollection 
is altered
}
}
}{code}
This test unexpectedly throws a ConcurrentModificationException.
The issue is that when calling {{iterator.remove()}} the 
{{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is empty 
and calls {{AbstractMultiValuedMap.this.remove(key);}}.

It may be better if the iterator of the inner collection had a reference on the 
iterator if the outer map and called {{containerIterator.remove()}} instead.
*Note:* this solution would again present issues if the user tries to add new 
elements in this now empty collection (which was removed from the parent).


In the current state, it is quite unclear why an exception is thrown, without 
debugging the code. 


  was:
Testcase:
{code}  @Test
public void test() {
MultiValuedMap multiMap = new 
HashSetValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(2, 20);
for (Collection innerCollection : 
multiMap.asMap().values()) {
for (Iterator iterator = 
innerCollection.iterator(); iterator.hasNext();) {
Integer i = iterator.next();
iterator.remove(); // only the innerCollection 
is altered
}
}
}{code}
This test unexpectedly throws a ConcurrentModificationException.
The issue is that when calling {{iterator.remove()}} the 
{{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is empty 
and calls {{AbstractMultiValuedMap.this.remove(key);}}.

It would be better if the iterator of the inner collection had a reference on 
the iterator if the outer map and called {{containerIterator.remove()}} instead.


In the current state, it is quite unclear why an exception is thrown, without 
debugging the code.


> Unexpected ConcurrentModificationException when altering Collection of a 
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
>  Issue Type: Bug
>Reporter: Christophe Schmaltz
>
> Testcase:
> {code}@Test
>   public void test() {
>   MultiValuedMap multiMap = new 
> HashSetValuedHashMap<>();
>   multiMap.put(1, 10);
>   multiMap.put(2, 20);
>   for (Collection innerCollection : 
> multiMap.asMap().values()) {
>   for (Iterator iterator = 
> innerCollection.iterator(); iterator.hasNext();) {
>   Integer i = iterator.next();
>   iterator.remove(); // only the innerCollection 
> is altered
>   }
>   }
>   }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the 
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is 
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on 
> the iterator if the outer map and called {{containerIterator.remove()}} 
> instead.
> *Note:* this solution would again present issues if the user tries to add new 
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without 
> debugging the code. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap

[Christophe Schmaltz (JIRA)]

Christophe Schmaltz created COLLECTIONS-663:
---

 Summary: Unexpected ConcurrentModificationException when altering 
Collection of a MultiValuedMap
 Key: COLLECTIONS-663
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
 Project: Commons Collections
  Issue Type: Bug
Reporter: Christophe Schmaltz


Testcase:
{code}  @Test
public void test() {
MultiValuedMap multiMap = new 
HashSetValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(2, 20);
for (Collection innerCollection : 
multiMap.asMap().values()) {
for (Iterator iterator = 
innerCollection.iterator(); iterator.hasNext();) {
Integer i = iterator.next();
iterator.remove(); // only the innerCollection 
is altered
}
}
}{code}
This test unexpectedly throws a ConcurrentModificationException.
The issue is that when calling {{iterator.remove()}} the 
{{multimap.AbstractMultiValuedMap.ValuesIterator}} detects that the Collection 
is empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.

It would be better if the iterator of the inner collection had a reference on 
the iterator if the outer map and called {{containerIterator.remove()}} instead.


In the current state, it is quite unclear why an exception is thrown, without 
debugging the code.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap

[Christophe Schmaltz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christophe Schmaltz updated COLLECTIONS-663:

Description: 
Testcase:
{code}  @Test
public void test() {
MultiValuedMap multiMap = new 
HashSetValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(2, 20);
for (Collection innerCollection : 
multiMap.asMap().values()) {
for (Iterator iterator = 
innerCollection.iterator(); iterator.hasNext();) {
Integer i = iterator.next();
iterator.remove(); // only the innerCollection 
is altered
}
}
}{code}
This test unexpectedly throws a ConcurrentModificationException.
The issue is that when calling {{iterator.remove()}} the 
{{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is empty 
and calls {{AbstractMultiValuedMap.this.remove(key);}}.

It would be better if the iterator of the inner collection had a reference on 
the iterator if the outer map and called {{containerIterator.remove()}} instead.


In the current state, it is quite unclear why an exception is thrown, without 
debugging the code.

  was:
Testcase:
{code}  @Test
public void test() {
MultiValuedMap multiMap = new 
HashSetValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(2, 20);
for (Collection innerCollection : 
multiMap.asMap().values()) {
for (Iterator iterator = 
innerCollection.iterator(); iterator.hasNext();) {
Integer i = iterator.next();
iterator.remove(); // only the innerCollection 
is altered
}
}
}{code}
This test unexpectedly throws a ConcurrentModificationException.
The issue is that when calling {{iterator.remove()}} the 
{{multimap.AbstractMultiValuedMap.ValuesIterator}} detects that the Collection 
is empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.

It would be better if the iterator of the inner collection had a reference on 
the iterator if the outer map and called {{containerIterator.remove()}} instead.


In the current state, it is quite unclear why an exception is thrown, without 
debugging the code.


> Unexpected ConcurrentModificationException when altering Collection of a 
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
>  Issue Type: Bug
>Reporter: Christophe Schmaltz
>
> Testcase:
> {code}@Test
>   public void test() {
>   MultiValuedMap multiMap = new 
> HashSetValuedHashMap<>();
>   multiMap.put(1, 10);
>   multiMap.put(2, 20);
>   for (Collection innerCollection : 
> multiMap.asMap().values()) {
>   for (Iterator iterator = 
> innerCollection.iterator(); iterator.hasNext();) {
>   Integer i = iterator.next();
>   iterator.remove(); // only the innerCollection 
> is altered
>   }
>   }
>   }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the 
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is 
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It would be better if the iterator of the inner collection had a reference on 
> the iterator if the outer map and called {{containerIterator.remove()}} 
> instead.
> In the current state, it is quite unclear why an exception is thrown, without 
> debugging the code.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (POOL-332) ObjectPool and KeyedObject pool should extend Closeable

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/POOL-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed POOL-332.
-
Resolution: Fixed

In Git master. There are still a small set of tests that could be cleaned up 
with try-with-resources blocks.

> ObjectPool and KeyedObject pool should extend Closeable
> ---
>
> Key: POOL-332
> URL: https://issues.apache.org/jira/browse/POOL-332
> Project: Commons Pool
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Priority: Major
> Fix For: 2.5
>
>
> {{ObjectPool}} and {{KeyedObject}} pool should extend {{java.io.Closeable}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (VFS-647) calling findFiles() causes copyFrom() to fail with a partially downloaded file.

[Bernd Eckenfels (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239069#comment-16239069
 ] 

Bernd Eckenfels edited comment on VFS-647 at 11/4/17 3:58 PM:
--

The filesystems instance is the same when the parameter (incl options and base 
URL) are the same. This is part of how the caching works. (VFS.getManager() is 
a Singleton, but I removed that part of the comment as your code does not close 
it)


was (Author: b.eckenfels):
As I Said the filesystems instance is the same when the parameter (+options) 
are the same.

> calling findFiles() causes copyFrom() to fail with a partially downloaded 
> file.
> ---
>
> Key: VFS-647
> URL: https://issues.apache.org/jira/browse/VFS-647
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0, 2.2
> Environment: Windows 7 and Linux Red Hat.
>Reporter: Kenji
>Priority: Minor
>
> Edit: The problem isn't specific to findFiles. All I need to do is have 1 
> thread downloads the file, and the other thread just log in, have a while 
> loop for x seconds where x < download time (using Thread.sleep(x) causes 
> interruption to happen immediately). Once x seconds passed, the download will 
> get interupted with pipe closed. Using the same hostname but different 
> username and password does not cause interruption.
> Original description:
> When using FileObject.copyFrom(remote, new AllFileSelector()) to download 
> file from remote to local directory. If SftpFileObject.findFiles(new 
> FileDepthSelector(1,1)) is called and finished, then the copyFrom will get 
> interrupted with error pipe closed.
> Below are test codes and stack trace error. In real scenario, this all 
> happens within 1 or 2 second time frame. However, with test scenario, I 
> wasn't able to reproduce it easily therefore I had to choose a file that 
> takes around 10 seconds to download and have Thread.sleep(5000) after 
> findFiles() call. Only tested jsch-0.1.52, jsch-0.1.54, commons-vfs2-2.0 and 
> commons-vfs2-2.2.
> {code:java}
> public class FtpClient {
>   
>   public static void main(String[] args) {
>   if (args.length < 5) {
>   throw new RuntimeException("args: host user pass local 
> remote");
>   }
>   String hostname = args[0];
>   String username = args[1];
>   String password = args[2];
>   int port = 22;
>   String local = args[3];
>   String remote = args[4];
>   final String remoteDir = remote.substring(0, Math.max(0, 
> remote.lastIndexOf("/")));
>   Thread t0 = new Thread() {
>   public void run() {
>   try (Ftp ftp = new Ftp(hostname, port)) {
>   ftp.login(username, password);
>   ftp.list(remoteDir);
>   System.out.println("findFiles() 
> completed.");
>   } catch (Exception e) {
>   e.printStackTrace();
>   }
>   }
>   };
>   
>   Thread ti = new Thread() {
>   public void run() {
>   try (Ftp ftp = new Ftp(hostname, port)) {
>   ftp.login(username, password);
>   ftp.download(local, remote);
>   } catch (Exception e) {
>   e.printStackTrace();
>   }
>   }
>   };
>   t0.start();
>   ti.start(); 
>   }
> }
> public class Ftp implements AutoCloseable {
>   private int timeout = 0;
>   private StaticUserAuthenticator userAuth;
>   private FileSystemOptions fileSysOpts;
>   private FileObject scr = null;
>   private FileSystemManager fsm = null;
>   private String hostName;
>   private int port = 0;
>   public Ftp(String remoteHost, int controlPort) throws 
> FileSystemException {
>   hostName = remoteHost;
>   port = controlPort;
>   fsm = VFS.getManager();
>   }
>   //login into a server with a valid account
>   public void login(String user, String password) throws IOException {
>   userAuth = new StaticUserAuthenticator(null, user, password); 
>   fileSysOpts = new FileSystemOptions();
>   
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fileSysOpts,
>  userAuth);
>   
> 

[jira] [Commented] (VFS-647) calling findFiles() causes copyFrom() to fail with a partially downloaded file.

[Bernd Eckenfels (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239069#comment-16239069
 ] 

Bernd Eckenfels commented on VFS-647:
-

As I Said the filesystems instance is the same when the parameter (+options) 
are the same.

> calling findFiles() causes copyFrom() to fail with a partially downloaded 
> file.
> ---
>
> Key: VFS-647
> URL: https://issues.apache.org/jira/browse/VFS-647
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0, 2.2
> Environment: Windows 7 and Linux Red Hat.
>Reporter: Kenji
>Priority: Minor
>
> Edit: The problem isn't specific to findFiles. All I need to do is have 1 
> thread downloads the file, and the other thread just log in, have a while 
> loop for x seconds where x < download time (using Thread.sleep(x) causes 
> interruption to happen immediately). Once x seconds passed, the download will 
> get interupted with pipe closed. Using the same hostname but different 
> username and password does not cause interruption.
> Original description:
> When using FileObject.copyFrom(remote, new AllFileSelector()) to download 
> file from remote to local directory. If SftpFileObject.findFiles(new 
> FileDepthSelector(1,1)) is called and finished, then the copyFrom will get 
> interrupted with error pipe closed.
> Below are test codes and stack trace error. In real scenario, this all 
> happens within 1 or 2 second time frame. However, with test scenario, I 
> wasn't able to reproduce it easily therefore I had to choose a file that 
> takes around 10 seconds to download and have Thread.sleep(5000) after 
> findFiles() call. Only tested jsch-0.1.52, jsch-0.1.54, commons-vfs2-2.0 and 
> commons-vfs2-2.2.
> {code:java}
> public class FtpClient {
>   
>   public static void main(String[] args) {
>   if (args.length < 5) {
>   throw new RuntimeException("args: host user pass local 
> remote");
>   }
>   String hostname = args[0];
>   String username = args[1];
>   String password = args[2];
>   int port = 22;
>   String local = args[3];
>   String remote = args[4];
>   final String remoteDir = remote.substring(0, Math.max(0, 
> remote.lastIndexOf("/")));
>   Thread t0 = new Thread() {
>   public void run() {
>   try (Ftp ftp = new Ftp(hostname, port)) {
>   ftp.login(username, password);
>   ftp.list(remoteDir);
>   System.out.println("findFiles() 
> completed.");
>   } catch (Exception e) {
>   e.printStackTrace();
>   }
>   }
>   };
>   
>   Thread ti = new Thread() {
>   public void run() {
>   try (Ftp ftp = new Ftp(hostname, port)) {
>   ftp.login(username, password);
>   ftp.download(local, remote);
>   } catch (Exception e) {
>   e.printStackTrace();
>   }
>   }
>   };
>   t0.start();
>   ti.start(); 
>   }
> }
> public class Ftp implements AutoCloseable {
>   private int timeout = 0;
>   private StaticUserAuthenticator userAuth;
>   private FileSystemOptions fileSysOpts;
>   private FileObject scr = null;
>   private FileSystemManager fsm = null;
>   private String hostName;
>   private int port = 0;
>   public Ftp(String remoteHost, int controlPort) throws 
> FileSystemException {
>   hostName = remoteHost;
>   port = controlPort;
>   fsm = VFS.getManager();
>   }
>   //login into a server with a valid account
>   public void login(String user, String password) throws IOException {
>   userAuth = new StaticUserAuthenticator(null, user, password); 
>   fileSysOpts = new FileSystemOptions();
>   
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fileSysOpts,
>  userAuth);
>   
> SftpFileSystemConfigBuilder.getInstance().setStrictHostKeyChecking(fileSysOpts,
>  "no");
>   
> SftpFileSystemConfigBuilder.getInstance().setTimeout(fileSysOpts, timeout);
>   
> SftpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fileSysOpts, 
> false);
>   scr = (FileObject)fsm.resolveFile("sftp://; + hostName, 
> fileSysOpts);
> 

[jira] [Resolved] (LANG-1362) Fix tests DateUtilsTest for Java 9 with en_GB locale

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved LANG-1362.
-
Resolution: Fixed
  Assignee: Gary Gregory

> Fix tests DateUtilsTest for Java 9 with en_GB locale
> 
>
> Key: LANG-1362
> URL: https://issues.apache.org/jira/browse/LANG-1362
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Reporter: Stephen Colebourne
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 3.7
>
>
> On Java 9 I see DateUtilsTest fail. This is because "MST7MDT" zone is not 
> formatted as "MST". I'm unclear as to why this is, but it is not relevant to 
> what the test is trying to do. As such, I've changed the zone to 
> "America/Denver" and changed the format letter from "z" to "XXX" to make it 
> more reliable.
> The PR also uses try-finally when setting the default time-zone to avoid 
> pollution of global state if a test fails (the pollution here made it look 
> like 8 test failures when there was only in fact 1).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang pull request #304: Fix DateUtilsTest to work reliably on Java 9

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/304


---

[jira] [Commented] (LANG-1362) Fix tests DateUtilsTest for Java 9 with en_GB locale

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239041#comment-16239041
 ] 

ASF GitHub Bot commented on LANG-1362:
--

Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/304


> Fix tests DateUtilsTest for Java 9 with en_GB locale
> 
>
> Key: LANG-1362
> URL: https://issues.apache.org/jira/browse/LANG-1362
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Reporter: Stephen Colebourne
>Priority: Minor
> Fix For: 3.7
>
>
> On Java 9 I see DateUtilsTest fail. This is because "MST7MDT" zone is not 
> formatted as "MST". I'm unclear as to why this is, but it is not relevant to 
> what the test is trying to do. As such, I've changed the zone to 
> "America/Denver" and changed the format letter from "z" to "XXX" to make it 
> more reliable.
> The PR also uses try-finally when setting the default time-zone to avoid 
> pollution of global state if a test fails (the pollution here made it look 
> like 8 test failures when there was only in fact 1).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (BCEL-299) Can not resolve symbol code

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/BCEL-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238996#comment-16238996
 ] 

ASF GitHub Bot commented on BCEL-299:
-

GitHub user zhangminglei opened a pull request:

https://github.com/apache/commons-bcel/pull/21

[BCEL-299] Fix resolve symbol error



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/zhangminglei/commons-bcel BCEL-299

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-bcel/pull/21.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 #21


commit 0f61c7c18f46d8bdb96e05b290baf629811ac6f1
Author: zhangminglei 
Date:   2017-11-04T13:14:18Z

[BCEL-299] Fix resolve symbol error




> Can not resolve symbol code
> ---
>
> Key: BCEL-299
> URL: https://issues.apache.org/jira/browse/BCEL-299
> Project: Commons BCEL
>  Issue Type: Bug
>Reporter: mingleizhang
>Priority: Blocker
>
> In ClassDumper.java example , We can not resolve symbol 
> {{Constants.JVM_CLASSFILE_MAGIC}} in processID method as Constants does not 
> have a JVM_CLASSFILE_MAGIC constant number.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (BCEL-299) Can not resolve symbol code

[mingleizhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/BCEL-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mingleizhang updated BCEL-299:
--
Description: In ClassDumper.java , We can not resolve symbol 
{{Constants.JVM_CLASSFILE_MAGIC}} in processID method as Constants does not 
have a JVM_CLASSFILE_MAGIC constant number.

> Can not resolve symbol code
> ---
>
> Key: BCEL-299
> URL: https://issues.apache.org/jira/browse/BCEL-299
> Project: Commons BCEL
>  Issue Type: Bug
>Reporter: mingleizhang
>Priority: Blocker
>
> In ClassDumper.java , We can not resolve symbol 
> {{Constants.JVM_CLASSFILE_MAGIC}} in processID method as Constants does not 
> have a JVM_CLASSFILE_MAGIC constant number.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (BCEL-299) Can not resolve symbol code

[mingleizhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/BCEL-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mingleizhang updated BCEL-299:
--
Description: In ClassDumper.java example , We can not resolve symbol 
{{Constants.JVM_CLASSFILE_MAGIC}} in processID method as Constants does not 
have a JVM_CLASSFILE_MAGIC constant number.  (was: In ClassDumper.java , We can 
not resolve symbol {{Constants.JVM_CLASSFILE_MAGIC}} in processID method as 
Constants does not have a JVM_CLASSFILE_MAGIC constant number.)

> Can not resolve symbol code
> ---
>
> Key: BCEL-299
> URL: https://issues.apache.org/jira/browse/BCEL-299
> Project: Commons BCEL
>  Issue Type: Bug
>Reporter: mingleizhang
>Priority: Blocker
>
> In ClassDumper.java example , We can not resolve symbol 
> {{Constants.JVM_CLASSFILE_MAGIC}} in processID method as Constants does not 
> have a JVM_CLASSFILE_MAGIC constant number.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (BCEL-299) Can not resolve symbol code

[mingleizhang (JIRA)]

mingleizhang created BCEL-299:
-

 Summary: Can not resolve symbol code
 Key: BCEL-299
 URL: https://issues.apache.org/jira/browse/BCEL-299
 Project: Commons BCEL
  Issue Type: Bug
Reporter: mingleizhang
Priority: Blocker






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (BCEL-298) Add some files to .gitignore

[mingleizhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/BCEL-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mingleizhang updated BCEL-298:
--
Priority: Minor  (was: Critical)

> Add some files to .gitignore
> 
>
> Key: BCEL-298
> URL: https://issues.apache.org/jira/browse/BCEL-298
> Project: Commons BCEL
>  Issue Type: Improvement
>Reporter: mingleizhang
>Priority: Minor
>
> We should not use git to track some files. Such as files with extension 
> suffix iml , suffix .idea if you are using Intellij IDEA as an IDE. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (BCEL-297) Incorrect override implementation of Object.equals

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/BCEL-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238969#comment-16238969
 ] 

ASF GitHub Bot commented on BCEL-297:
-

GitHub user zhangminglei opened a pull request:

https://github.com/apache/commons-bcel/pull/20

[BCEL-297] Fix NPE in BCELComparator concrete implementations.

This PR fix the potential NPE.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/zhangminglei/commons-bcel BCEL-297

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-bcel/pull/20.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 #20


commit 2338bf801caf437c3ee11cc666d2054c8f56d968
Author: zhangminglei 
Date:   2017-11-04T12:43:35Z

[BCEL-297] Fix NPE in BCELComparator concrete implementations.




> Incorrect override implementation of Object.equals
> --
>
> Key: BCEL-297
> URL: https://issues.apache.org/jira/browse/BCEL-297
> Project: Commons BCEL
>  Issue Type: Bug
>Reporter: Mark Roberts
>Priority: Minor
>
> classfile/JavaClass.java: 
> classfile/Field.java: 
> classfile/Constant.java:  
> classfile/Method.java:  
> generic/FieldGen.java:   
> generic/MethodGen.java:  
> all define a bcelComparator that overrides Object.equals.  However, they will 
> throw a null pointer exception for myConstant.equals(null) instead of 
> returning false.  This non-standard behavior should either be corrected or 
> documented.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IO-554) FileUtils.copyToFile(InputStream source, File destination) closes input stream

[Michele Mariotti (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michele Mariotti updated IO-554:

Summary: FileUtils.copyToFile(InputStream source, File destination) closes 
input stream  (was: copyToFile(InputStream source, File destination) closes 
input stream)

> FileUtils.copyToFile(InputStream source, File destination) closes 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
>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
(v6.4.14#64029)

[jira] [Commented] (IMAGING-198) Error while parsing JPEG with EXIF metadata with Imaging 1.0 (Sony DSC-R1)

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238960#comment-16238960
 ] 

Bruno P. Kinoshita commented on IMAGING-198:


Had some spare time today in a library nearby, and spent the day recapping the 
JPEG format (haven't looked at it since uni). Then spent some time in the 
evening debugging the code.

So far I found `jhead -v 99f.jpg` a helpful command, showing the segments 
found, and displaying the metadata hierarchically. The image attached to this 
issue is a JPEG/EXIF image. It contains the APP1 marker, which is parsed with 
Commons Imaging TiffReader.

This reader finds the initial directory, with 16 entries. All parsed 
successfully.

Then the TiffReader reads another directory. And here's where I will have to 
continue investigating it later.

This next directory starts with offset 0, and the ByteSource that it has 
reference is the initial ByteSource used for the first directory. This 
ByteSource has 764 bytes. But this second directory has 9128 bytes. And hence 
we have an exception in one of the if's that are used to prevent array out of 
bounds issues.

Just need to re-read about the EXIF format, and its directories. See how TIFF 
differs in regards to EXIF, directories, ordering. Could be that TIFF expects 
this second directory, as after that some code is iterating subdirectories...

> Error while parsing JPEG with EXIF metadata with Imaging 1.0 (Sony DSC-R1)
> --
>
> Key: IMAGING-198
> URL: https://issues.apache.org/jira/browse/IMAGING-198
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0
> Environment: Windows and Java 7u80
>Reporter: Samuel
>Assignee: Bruno P. Kinoshita
>Priority: Major
>  Labels: EXIF, JPEG
> Attachments: 99f.jpg
>
>
> An example of a JPEG image with EXIF metadata, coming from a Sony DSC-R1 
> camera, that will not be parsed with commons-imaging 1.0.
> http://imgur.com/a/fl9D9



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (BCEL-297) Incorrect override implementation of Object.equals

[mingleizhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/BCEL-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238958#comment-16238958
 ] 

mingleizhang commented on BCEL-297:
---

Hey, [~markro] We can just use {{Objects.equals}} to avoid this issue. Instead 
of throw a null pointer exception. but a false instead. I will give a PR to 
this issue. Thanks.

> Incorrect override implementation of Object.equals
> --
>
> Key: BCEL-297
> URL: https://issues.apache.org/jira/browse/BCEL-297
> Project: Commons BCEL
>  Issue Type: Bug
>Reporter: Mark Roberts
>Priority: Minor
>
> classfile/JavaClass.java: 
> classfile/Field.java: 
> classfile/Constant.java:  
> classfile/Method.java:  
> generic/FieldGen.java:   
> generic/MethodGen.java:  
> all define a bcelComparator that overrides Object.equals.  However, they will 
> throw a null pointer exception for myConstant.equals(null) instead of 
> returning false.  This non-standard behavior should either be corrected or 
> documented.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (BCEL-298) Add some files to .gitignore

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/BCEL-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238954#comment-16238954
 ] 

ASF GitHub Bot commented on BCEL-298:
-

GitHub user zhangminglei opened a pull request:

https://github.com/apache/commons-bcel/pull/19

[BCEL-298] Add some files to .gitignore



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/zhangminglei/commons-bcel BCEL-298

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-bcel/pull/19.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 #19


commit e88b2cc6c0b31ac6d260310947c778a39d9c36c3
Author: zhangminglei 
Date:   2017-11-04T12:14:14Z

[BCEL-298] Add some files to .gitignore




> Add some files to .gitignore
> 
>
> Key: BCEL-298
> URL: https://issues.apache.org/jira/browse/BCEL-298
> Project: Commons BCEL
>  Issue Type: Improvement
>Reporter: mingleizhang
>Priority: Critical
>
> We should not use git to track some files. Such as files with extension 
> suffix iml , suffix .idea if you are using Intellij IDEA as an IDE. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (BCEL-298) Add some files to .gitignore

[mingleizhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/BCEL-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238948#comment-16238948
 ] 

mingleizhang edited comment on BCEL-298 at 11/4/17 12:04 PM:
-

Can anyone give me a permission that can contribute code to BCEL and assignee 
it to myself  ? Thanks in advance.


was (Author: mingleizhang):
Can anyone give me a permission that can contributor code to BCEL and assignee 
it to myself  ? Thanks in advance.

> Add some files to .gitignore
> 
>
> Key: BCEL-298
> URL: https://issues.apache.org/jira/browse/BCEL-298
> Project: Commons BCEL
>  Issue Type: Improvement
>Reporter: mingleizhang
>Priority: Critical
>
> We should not use git to track some files. Such as files with extension 
> suffix iml , suffix .idea if you are using Intellij IDEA as an IDE. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (BCEL-298) Add some files to .gitignore

[mingleizhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/BCEL-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238948#comment-16238948
 ] 

mingleizhang commented on BCEL-298:
---

Can anyone give me a permission that can contributor code to BCEL and assignee 
it to myself  ? Thanks in advance.

> Add some files to .gitignore
> 
>
> Key: BCEL-298
> URL: https://issues.apache.org/jira/browse/BCEL-298
> Project: Commons BCEL
>  Issue Type: Improvement
>Reporter: mingleizhang
>Priority: Critical
>
> We should not use git to track some files. Such as files with extension 
> suffix iml , suffix .idea if you are using Intellij IDEA as an IDE. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (BCEL-298) Add some files to .gitignore

[mingleizhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/BCEL-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mingleizhang updated BCEL-298:
--
Description: We should not use git to track some files. Such as files with 
extension suffix iml , suffix .idea if you are using Intellij IDEA as an IDE. 

> Add some files to .gitignore
> 
>
> Key: BCEL-298
> URL: https://issues.apache.org/jira/browse/BCEL-298
> Project: Commons BCEL
>  Issue Type: Improvement
>Reporter: mingleizhang
>Priority: Critical
>
> We should not use git to track some files. Such as files with extension 
> suffix iml , suffix .idea if you are using Intellij IDEA as an IDE. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (BCEL-298) Add some files to .gitignore

[mingleizhang (JIRA)]

mingleizhang created BCEL-298:
-

 Summary: Add some files to .gitignore
 Key: BCEL-298
 URL: https://issues.apache.org/jira/browse/BCEL-298
 Project: Commons BCEL
  Issue Type: Improvement
Reporter: mingleizhang
Priority: Critical






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-106) Exception thrown in ExtendedMessageFormat using quotes with custom registry

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238930#comment-16238930
 ] 

ASF GitHub Bot commented on TEXT-106:
-

Github user kinow commented on the issue:

https://github.com/apache/commons-text/pull/73
  
Already done @ben12! Hope first pull request of many :-)


> Exception thrown in ExtendedMessageFormat using quotes with custom registry
> ---
>
> Key: TEXT-106
> URL: https://issues.apache.org/jira/browse/TEXT-106
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Benoît Moreau
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: ExtendedMessageFormat.java.patch, 
> ExtendedMessageFormatTest.java.patch
>
>
> An exception is thrown when a quote is used just before end brace of format 
> element definition when a custom registry is used.
> This exception is not thrown when a blank space is added before the end brace.
> {code:java}
> public static void main(String[] args)
> {
>   String pattern   = "TEST: {0,choice,0#0|0<'1'}";
>   String patternWorkaround = "TEST: {0,choice,0#0|0<'1' }"; // a space 
> after quote
>   // Works fine
>   MessageFormat format0 = new MessageFormat(pattern);
>   System.out.println(format0.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format0.format(new Integer[] { 1 })); // "TEST: 1"
>   // Works fine
>   ExtendedMessageFormat format1 = new ExtendedMessageFormat(pattern);
>   System.out.println(format1.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format1.format(new Integer[] { 1 })); // "TEST: 1"
>   // Works fine
>   ExtendedMessageFormat format2 = new 
> ExtendedMessageFormat(patternWorkaround, new HashMap FormatFactory>());
>   System.out.println(format2.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format2.format(new Integer[] { 1 })); // "TEST: 1 "
>   // Doesn't work
>   ExtendedMessageFormat format3 = new ExtendedMessageFormat(pattern, new 
> HashMap());
>   System.out.println(format3.format(new Integer[] { 0 })); // Exception 
> in thread "main" java.lang.IllegalArgumentException: Unterminated format 
> element at position 9
>   System.out.println(format3.format(new Integer[] { 1 }));
> }
> {code}
> Expected behavior: This exception should not be thrown.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-106) Exception thrown in ExtendedMessageFormat using quotes with custom registry

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238928#comment-16238928
 ] 

ASF GitHub Bot commented on TEXT-106:
-

Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/73
  

[![Coverage 
Status](https://coveralls.io/builds/14037929/badge)](https://coveralls.io/builds/14037929)

Coverage increased (+0.1%) to 98.417% when pulling 
**3554c40a09288ba85313219c58e8084f3dcd885f on kinow:TEXT-106** into 
**e55d0ac1c17a7fd71dbb4f65034c7b739be6a35a on apache:master**.



> Exception thrown in ExtendedMessageFormat using quotes with custom registry
> ---
>
> Key: TEXT-106
> URL: https://issues.apache.org/jira/browse/TEXT-106
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Benoît Moreau
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: ExtendedMessageFormat.java.patch, 
> ExtendedMessageFormatTest.java.patch
>
>
> An exception is thrown when a quote is used just before end brace of format 
> element definition when a custom registry is used.
> This exception is not thrown when a blank space is added before the end brace.
> {code:java}
> public static void main(String[] args)
> {
>   String pattern   = "TEST: {0,choice,0#0|0<'1'}";
>   String patternWorkaround = "TEST: {0,choice,0#0|0<'1' }"; // a space 
> after quote
>   // Works fine
>   MessageFormat format0 = new MessageFormat(pattern);
>   System.out.println(format0.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format0.format(new Integer[] { 1 })); // "TEST: 1"
>   // Works fine
>   ExtendedMessageFormat format1 = new ExtendedMessageFormat(pattern);
>   System.out.println(format1.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format1.format(new Integer[] { 1 })); // "TEST: 1"
>   // Works fine
>   ExtendedMessageFormat format2 = new 
> ExtendedMessageFormat(patternWorkaround, new HashMap FormatFactory>());
>   System.out.println(format2.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format2.format(new Integer[] { 1 })); // "TEST: 1 "
>   // Doesn't work
>   ExtendedMessageFormat format3 = new ExtendedMessageFormat(pattern, new 
> HashMap());
>   System.out.println(format3.format(new Integer[] { 0 })); // Exception 
> in thread "main" java.lang.IllegalArgumentException: Unterminated format 
> element at position 9
>   System.out.println(format3.format(new Integer[] { 1 }));
> }
> {code}
> Expected behavior: This exception should not be thrown.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-106) Exception thrown in ExtendedMessageFormat using quotes with custom registry

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238929#comment-16238929
 ] 

ASF GitHub Bot commented on TEXT-106:
-

Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/73
  

[![Coverage 
Status](https://coveralls.io/builds/14037929/badge)](https://coveralls.io/builds/14037929)

Coverage increased (+0.1%) to 98.417% when pulling 
**3554c40a09288ba85313219c58e8084f3dcd885f on kinow:TEXT-106** into 
**e55d0ac1c17a7fd71dbb4f65034c7b739be6a35a on apache:master**.



> Exception thrown in ExtendedMessageFormat using quotes with custom registry
> ---
>
> Key: TEXT-106
> URL: https://issues.apache.org/jira/browse/TEXT-106
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Benoît Moreau
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: ExtendedMessageFormat.java.patch, 
> ExtendedMessageFormatTest.java.patch
>
>
> An exception is thrown when a quote is used just before end brace of format 
> element definition when a custom registry is used.
> This exception is not thrown when a blank space is added before the end brace.
> {code:java}
> public static void main(String[] args)
> {
>   String pattern   = "TEST: {0,choice,0#0|0<'1'}";
>   String patternWorkaround = "TEST: {0,choice,0#0|0<'1' }"; // a space 
> after quote
>   // Works fine
>   MessageFormat format0 = new MessageFormat(pattern);
>   System.out.println(format0.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format0.format(new Integer[] { 1 })); // "TEST: 1"
>   // Works fine
>   ExtendedMessageFormat format1 = new ExtendedMessageFormat(pattern);
>   System.out.println(format1.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format1.format(new Integer[] { 1 })); // "TEST: 1"
>   // Works fine
>   ExtendedMessageFormat format2 = new 
> ExtendedMessageFormat(patternWorkaround, new HashMap FormatFactory>());
>   System.out.println(format2.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format2.format(new Integer[] { 1 })); // "TEST: 1 "
>   // Doesn't work
>   ExtendedMessageFormat format3 = new ExtendedMessageFormat(pattern, new 
> HashMap());
>   System.out.println(format3.format(new Integer[] { 0 })); // Exception 
> in thread "main" java.lang.IllegalArgumentException: Unterminated format 
> element at position 9
>   System.out.println(format3.format(new Integer[] { 1 }));
> }
> {code}
> Expected behavior: This exception should not be thrown.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-106) Exception thrown in ExtendedMessageFormat using quotes with custom registry

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238924#comment-16238924
 ] 

ASF GitHub Bot commented on TEXT-106:
-

Github user ben12 commented on the issue:

https://github.com/apache/commons-text/pull/73
  
I have corrected my patch https://github.com/kinow/commons-text/pull/1

It is my first pull request, so if I have understand the worlflow, kinow 
must accept it to re-pull it here.


> Exception thrown in ExtendedMessageFormat using quotes with custom registry
> ---
>
> Key: TEXT-106
> URL: https://issues.apache.org/jira/browse/TEXT-106
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Benoît Moreau
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: ExtendedMessageFormat.java.patch, 
> ExtendedMessageFormatTest.java.patch
>
>
> An exception is thrown when a quote is used just before end brace of format 
> element definition when a custom registry is used.
> This exception is not thrown when a blank space is added before the end brace.
> {code:java}
> public static void main(String[] args)
> {
>   String pattern   = "TEST: {0,choice,0#0|0<'1'}";
>   String patternWorkaround = "TEST: {0,choice,0#0|0<'1' }"; // a space 
> after quote
>   // Works fine
>   MessageFormat format0 = new MessageFormat(pattern);
>   System.out.println(format0.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format0.format(new Integer[] { 1 })); // "TEST: 1"
>   // Works fine
>   ExtendedMessageFormat format1 = new ExtendedMessageFormat(pattern);
>   System.out.println(format1.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format1.format(new Integer[] { 1 })); // "TEST: 1"
>   // Works fine
>   ExtendedMessageFormat format2 = new 
> ExtendedMessageFormat(patternWorkaround, new HashMap FormatFactory>());
>   System.out.println(format2.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format2.format(new Integer[] { 1 })); // "TEST: 1 "
>   // Doesn't work
>   ExtendedMessageFormat format3 = new ExtendedMessageFormat(pattern, new 
> HashMap());
>   System.out.println(format3.format(new Integer[] { 0 })); // Exception 
> in thread "main" java.lang.IllegalArgumentException: Unterminated format 
> element at position 9
>   System.out.println(format3.format(new Integer[] { 1 }));
> }
> {code}
> Expected behavior: This exception should not be thrown.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IO-554) copyToFile(InputStream source, File destination) closes input stream

[Michele Mariotti (JIRA)]

Michele Mariotti created IO-554:
---

 Summary: copyToFile(InputStream source, File destination) closes 
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
Priority: Blocker
 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
(v6.4.14#64029)

[jira] [Commented] (TEXT-106) Exception thrown in ExtendedMessageFormat using quotes with custom registry

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238905#comment-16238905
 ] 

ASF GitHub Bot commented on TEXT-106:
-

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-text/pull/73
  
patch has some check-style violations, see: 
https://travis-ci.org/apache/commons-text/jobs/294087452


> Exception thrown in ExtendedMessageFormat using quotes with custom registry
> ---
>
> Key: TEXT-106
> URL: https://issues.apache.org/jira/browse/TEXT-106
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Benoît Moreau
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: ExtendedMessageFormat.java.patch, 
> ExtendedMessageFormatTest.java.patch
>
>
> An exception is thrown when a quote is used just before end brace of format 
> element definition when a custom registry is used.
> This exception is not thrown when a blank space is added before the end brace.
> {code:java}
> public static void main(String[] args)
> {
>   String pattern   = "TEST: {0,choice,0#0|0<'1'}";
>   String patternWorkaround = "TEST: {0,choice,0#0|0<'1' }"; // a space 
> after quote
>   // Works fine
>   MessageFormat format0 = new MessageFormat(pattern);
>   System.out.println(format0.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format0.format(new Integer[] { 1 })); // "TEST: 1"
>   // Works fine
>   ExtendedMessageFormat format1 = new ExtendedMessageFormat(pattern);
>   System.out.println(format1.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format1.format(new Integer[] { 1 })); // "TEST: 1"
>   // Works fine
>   ExtendedMessageFormat format2 = new 
> ExtendedMessageFormat(patternWorkaround, new HashMap FormatFactory>());
>   System.out.println(format2.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format2.format(new Integer[] { 1 })); // "TEST: 1 "
>   // Doesn't work
>   ExtendedMessageFormat format3 = new ExtendedMessageFormat(pattern, new 
> HashMap());
>   System.out.println(format3.format(new Integer[] { 0 })); // Exception 
> in thread "main" java.lang.IllegalArgumentException: Unterminated format 
> element at position 9
>   System.out.println(format3.format(new Integer[] { 1 }));
> }
> {code}
> Expected behavior: This exception should not be thrown.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)