[jira] [Created] (CODEC-184) NullPointerException in DoubleMetaPhone.isDoubleMetaphoneEqual when using empty strings
Cyrille Artho created CODEC-184:
---
Summary: NullPointerException in
DoubleMetaPhone.isDoubleMetaphoneEqual when using empty strings
Key: CODEC-184
URL: https://issues.apache.org/jira/browse/CODEC-184
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.9
Environment: Mac OS 10.9, Java 6 or 7
Reporter: Cyrille Artho
Attachments: BugReport.java
isDoubleMetaphoneEqual does not work with empty strings: The following test
throws a NullPointerException:
public void test1() throws Throwable {
org.apache.commons.codec.language.DoubleMetaphone var0 = new
org.apache.commons.codec.language.DoubleMetaphone();
boolean var3 = var0.isDoubleMetaphoneEqual(, , false);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CODEC-184) NullPointerException in DoubleMetaPhone.isDoubleMetaphoneEqual when using empty strings
[
https://issues.apache.org/jira/browse/CODEC-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cyrille Artho updated CODEC-184:
Attachment: BugReport.java
Self-contained JUnit test class (with one test case) to reproduce bug.
NullPointerException in DoubleMetaPhone.isDoubleMetaphoneEqual when using
empty strings
---
Key: CODEC-184
URL: https://issues.apache.org/jira/browse/CODEC-184
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.9
Environment: Mac OS 10.9, Java 6 or 7
Reporter: Cyrille Artho
Attachments: BugReport.java
isDoubleMetaphoneEqual does not work with empty strings: The following test
throws a NullPointerException:
public void test1() throws Throwable {
org.apache.commons.codec.language.DoubleMetaphone var0 = new
org.apache.commons.codec.language.DoubleMetaphone();
boolean var3 = var0.isDoubleMetaphoneEqual(, , false);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (PRIMITIVES-17) equals/hashCode mismatch
Cyrille Artho created PRIMITIVES-17: --- Summary: equals/hashCode mismatch Key: PRIMITIVES-17 URL: https://issues.apache.org/jira/browse/PRIMITIVES-17 Project: Commons Primitives Issue Type: Bug Affects Versions: 1.0 Environment: Mac OS 10.9 with Java 6 or 7 Reporter: Cyrille Artho Two automatically generated tests that wrap singleton lists in different ways result in two lists being equal, but having a distinct hash code. See the attached two JUnit tests. Both tests show a similar issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PRIMITIVES-17) equals/hashCode mismatch
[ https://issues.apache.org/jira/browse/PRIMITIVES-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cyrille Artho updated PRIMITIVES-17: Attachment: Report.java equals/hashCode mismatch Key: PRIMITIVES-17 URL: https://issues.apache.org/jira/browse/PRIMITIVES-17 Project: Commons Primitives Issue Type: Bug Affects Versions: 1.0 Environment: Mac OS 10.9 with Java 6 or 7 Reporter: Cyrille Artho Attachments: Report.java Two automatically generated tests that wrap singleton lists in different ways result in two lists being equal, but having a distinct hash code. See the attached two JUnit tests. Both tests show a similar issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PRIMITIVES-17) equals/hashCode mismatch
[ https://issues.apache.org/jira/browse/PRIMITIVES-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cyrille Artho updated PRIMITIVES-17: Description: Two automatically generated tests that wrap singleton lists in different ways result in two lists being equal, but having a distinct hash code. See the attached two JUnit tests in Report.java. Both tests show a similar issue. was: Two automatically generated tests that wrap singleton lists in different ways result in two lists being equal, but having a distinct hash code. See the attached two JUnit tests. Both tests show a similar issue. equals/hashCode mismatch Key: PRIMITIVES-17 URL: https://issues.apache.org/jira/browse/PRIMITIVES-17 Project: Commons Primitives Issue Type: Bug Affects Versions: 1.0 Environment: Mac OS 10.9 with Java 6 or 7 Reporter: Cyrille Artho Attachments: Report.java Two automatically generated tests that wrap singleton lists in different ways result in two lists being equal, but having a distinct hash code. See the attached two JUnit tests in Report.java. Both tests show a similar issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-923) JDK 1.8 Changes
[ https://issues.apache.org/jira/browse/LANG-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-923: --- Component/s: General JDK 1.8 Changes --- Key: LANG-923 URL: https://issues.apache.org/jira/browse/LANG-923 Project: Commons Lang Issue Type: Task Components: General Reporter: Henri Yandell Fix For: 4.0 Omnibus issue to cover any JDK 1.8 related changes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-967) Code should never catch and ignore all Throwables
[
https://issues.apache.org/jira/browse/LANG-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-967:
---
Component/s: lang.exception.*
Code should never catch and ignore all Throwables
-
Key: LANG-967
URL: https://issues.apache.org/jira/browse/LANG-967
Project: Commons Lang
Issue Type: New Feature
Components: lang.exception.*
Reporter: Sebb
Fix For: Patch Needed
Code should never catch and ignore all Throwables - ThreadDeath and
VirtualMachineError must be rethrown.
It would be useful to provide a method to enforce this behaviour.
For example,. as is done by the Tomcat method \[1] with source here \[2]
Sample usage:
{code}
try {
reader.close();
} catch (Throwable u) {
ExceptionUtils.handleThrowable(u);
}
{code}
\[1] org.apache.tomcat.util.ExceptionUtils#handleThrowable()
\[2]
https://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/tomcat/util/ExceptionUtils.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-986) DurationFormatUtils.formatDuration accepts formats with year/month but cannot use them
[ https://issues.apache.org/jira/browse/LANG-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-986: --- Component/s: lang.time.* DurationFormatUtils.formatDuration accepts formats with year/month but cannot use them -- Key: LANG-986 URL: https://issues.apache.org/jira/browse/LANG-986 Project: Commons Lang Issue Type: Improvement Components: lang.time.* Reporter: Sebb Fix For: Discussion The method DurationFormatUtils.formatDuration does not validate that the format is applicable. The method does not calculate months and years, so these values will be 0 if the format contains y or M. Perhaps the method should throw IAE if one of the unused format chars is used? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-979) TypeUtils.parameterizeWithOwner - wrong format descriptor for invalid number of type parameters
[ https://issues.apache.org/jira/browse/LANG-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-979: --- Component/s: lang.reflect.* TypeUtils.parameterizeWithOwner - wrong format descriptor for invalid number of type parameters - Key: LANG-979 URL: https://issues.apache.org/jira/browse/LANG-979 Project: Commons Lang Issue Type: Bug Components: lang.reflect.* Reporter: Sebb Priority: Minor Fix For: Patch Needed The TypeUtils.parameterizeWithOwner method uses the following format string: invalid number of type parameters specified: expected %s, got %s with parameters that are actually ints. This means that the parameters are boxed into Integers and then converted to Strings by the formatter. Seems to me it would make more sense to either create the Strings directly from the ints, or box the ints and use %d for the place holders. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (IO-295) FileUtils.isSymlinks misses symlink folders on Windows
[ https://issues.apache.org/jira/browse/IO-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell reopened IO-295: -- Reopening per the comments. FileUtils.isSymlinks misses symlink folders on Windows -- Key: IO-295 URL: https://issues.apache.org/jira/browse/IO-295 Project: Commons IO Issue Type: Bug Affects Versions: 2.1 Environment: Windows 7 64 bit, Oracle Java 7 Reporter: Ron Gross Attachments: IO-295-1.patch, IO-295.patch I created a symlink folder via mklink. Then, while debugging, I noticed that FileUtils.isSymlink() returns false on this directory, while Java 7's Files.isSymbolicLink() returns true. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (IO-436) Improper JavaDoc comment for FilenameUtils.indexOfExtension
Christoph Schneegans created IO-436: --- Summary: Improper JavaDoc comment for FilenameUtils.indexOfExtension Key: IO-436 URL: https://issues.apache.org/jira/browse/IO-436 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 2.4 Reporter: Christoph Schneegans Priority: Trivial The method FilenameUtils.indexOfExtension contains this JavaDoc comment: * @param filename the filename to find the last path separator in, null returns -1 * @return the index of the last separator character, or -1 if there * is no such character This comment was obviously copied from the FilenameUtils.indexOfLastSeparator method, where it makes perfect sense. The JavaDoc comment for FilenameUtils.indexOfExtension should rather read e.g. as follows: * @param filename the filename to find the last extension separator in, null returns -1 * @return the index of the last extension separator character, or -1 if there * is no such character -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CODEC-184) NullPointerException in DoubleMetaPhone.isDoubleMetaphoneEqual when using empty strings
[
https://issues.apache.org/jira/browse/CODEC-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated CODEC-184:
---
Description:
isDoubleMetaphoneEqual does not work with empty strings: The following test
throws a NullPointerException:
{code:java}
public void test1() throws Throwable {
org.apache.commons.codec.language.DoubleMetaphone var0 = new
org.apache.commons.codec.language.DoubleMetaphone();
boolean var3 = var0.isDoubleMetaphoneEqual(, , false);
}
{code}
was:
isDoubleMetaphoneEqual does not work with empty strings: The following test
throws a NullPointerException:
public void test1() throws Throwable {
org.apache.commons.codec.language.DoubleMetaphone var0 = new
org.apache.commons.codec.language.DoubleMetaphone();
boolean var3 = var0.isDoubleMetaphoneEqual(, , false);
}
NullPointerException in DoubleMetaPhone.isDoubleMetaphoneEqual when using
empty strings
---
Key: CODEC-184
URL: https://issues.apache.org/jira/browse/CODEC-184
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.9
Environment: Mac OS 10.9, Java 6 or 7
Reporter: Cyrille Artho
Attachments: BugReport.java
isDoubleMetaphoneEqual does not work with empty strings: The following test
throws a NullPointerException:
{code:java}
public void test1() throws Throwable {
org.apache.commons.codec.language.DoubleMetaphone var0 = new
org.apache.commons.codec.language.DoubleMetaphone();
boolean var3 = var0.isDoubleMetaphoneEqual(, , false);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CODEC-184) NullPointerException in DoubleMetaPhone.isDoubleMetaphoneEqual when using empty strings
[
https://issues.apache.org/jira/browse/CODEC-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated CODEC-184:
---
Description:
{{isDoubleMetaphoneEqual}} does not work with empty strings: The following test
throws a {{NullPointerException}}:
{code:java}
public void test1() throws Throwable {
org.apache.commons.codec.language.DoubleMetaphone var0 = new
org.apache.commons.codec.language.DoubleMetaphone();
boolean var3 = var0.isDoubleMetaphoneEqual(, , false);
}
{code}
was:
isDoubleMetaphoneEqual does not work with empty strings: The following test
throws a NullPointerException:
{code:java}
public void test1() throws Throwable {
org.apache.commons.codec.language.DoubleMetaphone var0 = new
org.apache.commons.codec.language.DoubleMetaphone();
boolean var3 = var0.isDoubleMetaphoneEqual(, , false);
}
{code}
NullPointerException in DoubleMetaPhone.isDoubleMetaphoneEqual when using
empty strings
---
Key: CODEC-184
URL: https://issues.apache.org/jira/browse/CODEC-184
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.9
Environment: Mac OS 10.9, Java 6 or 7
Reporter: Cyrille Artho
Attachments: BugReport.java
{{isDoubleMetaphoneEqual}} does not work with empty strings: The following
test throws a {{NullPointerException}}:
{code:java}
public void test1() throws Throwable {
org.apache.commons.codec.language.DoubleMetaphone var0 = new
org.apache.commons.codec.language.DoubleMetaphone();
boolean var3 = var0.isDoubleMetaphoneEqual(, , false);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IO-436) Improper JavaDoc comment for FilenameUtils.indexOfExtension
[ https://issues.apache.org/jira/browse/IO-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Schneegans updated IO-436: Description: The method FilenameUtils.indexOfExtension contains this JavaDoc comment: \* @param filename the filename to find the last path separator in, null returns -1 \* @return the index of the last separator character, or -1 if there \* is no such character This comment was obviously copied from the FilenameUtils.indexOfLastSeparator method, where it makes perfect sense. The JavaDoc comment for FilenameUtils.indexOfExtension should rather read e.g. as follows: \* @param filename the filename to find the last extension separator in, null returns -1 \* @return the index of the last extension separator character, or -1 if there \* is no such character was: The method FilenameUtils.indexOfExtension contains this JavaDoc comment: * @param filename the filename to find the last path separator in, null returns -1 * @return the index of the last separator character, or -1 if there * is no such character This comment was obviously copied from the FilenameUtils.indexOfLastSeparator method, where it makes perfect sense. The JavaDoc comment for FilenameUtils.indexOfExtension should rather read e.g. as follows: * @param filename the filename to find the last extension separator in, null returns -1 * @return the index of the last extension separator character, or -1 if there * is no such character Improper JavaDoc comment for FilenameUtils.indexOfExtension --- Key: IO-436 URL: https://issues.apache.org/jira/browse/IO-436 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 2.4 Reporter: Christoph Schneegans Priority: Trivial Labels: documentation The method FilenameUtils.indexOfExtension contains this JavaDoc comment: \* @param filename the filename to find the last path separator in, null returns -1 \* @return the index of the last separator character, or -1 if there \* is no such character This comment was obviously copied from the FilenameUtils.indexOfLastSeparator method, where it makes perfect sense. The JavaDoc comment for FilenameUtils.indexOfExtension should rather read e.g. as follows: \* @param filename the filename to find the last extension separator in, null returns -1 \* @return the index of the last extension separator character, or -1 if there \* is no such character -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CODEC-184) NullPointerException in DoubleMetaPhone.isDoubleMetaphoneEqual when using empty strings
[
https://issues.apache.org/jira/browse/CODEC-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved CODEC-184.
Resolution: Fixed
Fix Version/s: 1.10
Assignee: Gary Gregory
Thank you for the bug report.
{noformat}
commit -m action dev=ggregory type=add issue=CODEC-184 due-to=Cyrille
ArthoNullPointerException in DoubleMetaPhone.isDoubleMetaphoneEqual when
using empty strings/action
C:/vcs/svn/apache/commons/trunks-proper/codec/src/test/java/org/apache/commons/codec/language/DoubleMetaphoneTest.java
C:/vcs/svn/apache/commons/trunks-proper/codec/src/main/java/org/apache/commons/codec/binary/CharSequenceUtils.java
C:/vcs/svn/apache/commons/trunks-proper/codec/src/changes/changes.xml
C:/vcs/svn/apache/commons/trunks-proper/codec/src/main/java/org/apache/commons/codec/language/DoubleMetaphone.java
C:/vcs/svn/apache/commons/trunks-proper/codec/src/main/java/org/apache/commons/codec/binary/StringUtils.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/codec/src/changes/changes.xml
Adding
C:/vcs/svn/apache/commons/trunks-proper/codec/src/main/java/org/apache/commons/codec/binary/CharSequenceUtils.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/codec/src/main/java/org/apache/commons/codec/binary/StringUtils.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/codec/src/main/java/org/apache/commons/codec/language/DoubleMetaphone.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/codec/src/test/java/org/apache/commons/codec/language/DoubleMetaphoneTest.java
Transmitting file data ...
Committed revision 1586300.
{noformat}
NullPointerException in DoubleMetaPhone.isDoubleMetaphoneEqual when using
empty strings
---
Key: CODEC-184
URL: https://issues.apache.org/jira/browse/CODEC-184
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.9
Environment: Mac OS 10.9, Java 6 or 7
Reporter: Cyrille Artho
Assignee: Gary Gregory
Fix For: 1.10
Attachments: BugReport.java
{{isDoubleMetaphoneEqual}} does not work with empty strings: The following
test throws a {{NullPointerException}}:
{code:java}
public void test1() throws Throwable {
org.apache.commons.codec.language.DoubleMetaphone var0 = new
org.apache.commons.codec.language.DoubleMetaphone();
boolean var3 = var0.isDoubleMetaphoneEqual(, , false);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (IO-436) Improper JavaDoc comment for FilenameUtils.indexOfExtension
[ https://issues.apache.org/jira/browse/IO-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved IO-436. - Resolution: Fixed Fix Version/s: 2.5 Assignee: Gary Gregory Thank you for the report! Improper JavaDoc comment for FilenameUtils.indexOfExtension --- Key: IO-436 URL: https://issues.apache.org/jira/browse/IO-436 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 2.4 Reporter: Christoph Schneegans Assignee: Gary Gregory Priority: Trivial Labels: documentation Fix For: 2.5 The method FilenameUtils.indexOfExtension contains this JavaDoc comment: \* @param filename the filename to find the last path separator in, null returns -1 \* @return the index of the last separator character, or -1 if there \* is no such character This comment was obviously copied from the FilenameUtils.indexOfLastSeparator method, where it makes perfect sense. The JavaDoc comment for FilenameUtils.indexOfExtension should rather read e.g. as follows: \* @param filename the filename to find the last extension separator in, null returns -1 \* @return the index of the last extension separator character, or -1 if there \* is no such character -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (IO-437) Make IOUtils.EOF public and reuse it in various classes
Gary Gregory created IO-437: --- Summary: Make IOUtils.EOF public and reuse it in various classes Key: IO-437 URL: https://issues.apache.org/jira/browse/IO-437 Project: Commons IO Issue Type: Improvement Components: Utilities Affects Versions: 2.4 Environment: Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T12:37:52-05:00) Maven home: C:\Java\apache-maven-3.2.1\bin\.. Java version: 1.7.0_51, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0_51\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary Gregory Assignee: Gary Gregory Fix For: 2.5 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (IO-437) Make IOUtils.EOF public and reuse it in various classes
[
https://issues.apache.org/jira/browse/IO-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved IO-437.
-
Resolution: Fixed
{noformat}
commit -m action issue=IO-437 dev=ggregory type=add... (17 paths
specified)
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/changes/changes.xml
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/EndianUtils.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/AutoCloseInputStream.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/CharSequenceInputStream.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/CharSequenceReader.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/ClosedInputStream.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/CountingInputStream.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/DemuxInputStream.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/NullInputStream.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/NullReader.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/ProxyInputStream.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/ProxyReader.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/ReaderInputStream.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/SwappedDataInputStream.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/Tailer.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/TeeInputStream.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/output/ByteArrayOutputStream.java
Transmitting file data ...
Committed revision 1586350.
{noformat}
These are the obvious changes.
Not changed are:
More places where -1 is used as a magic number but it is with different
semantics: index not found.
There is another classes which seems to use -1 for both EOF and index not found.
Make IOUtils.EOF public and reuse it in various classes
---
Key: IO-437
URL: https://issues.apache.org/jira/browse/IO-437
Project: Commons IO
Issue Type: Improvement
Components: Utilities
Affects Versions: 2.4
Environment: Apache Maven 3.2.1
(ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T12:37:52-05:00)
Maven home: C:\Java\apache-maven-3.2.1\bin\..
Java version: 1.7.0_51, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_51\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: 2.5
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DBCP-413) Closing a Connection does not close Statement objects created on that connection, by way of the close() method.
[ https://issues.apache.org/jira/browse/DBCP-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13965534#comment-13965534 ] Phil Steitz commented on DBCP-413: -- DBCP should both set the isClosed property on its wrapper for the PreparedStatement and close the actual JDBC statement when a connection borrowed from the pool is closed. The driver should treat repeated close on a statement as no-op. What does not make sense in this case is isClosed returning false. That could point to a DBCP bug (though not what the title for this issue suggests). If statement pooling is enabled and there are concurrent clients involved, this scenario is possible with the right timing and does not indicate a bug in DBCP - just reconfirms that clients should *not* use anything associated with a connection once it has been returned to the pool. Closing a Connection does not close Statement objects created on that connection, by way of the close() method. --- Key: DBCP-413 URL: https://issues.apache.org/jira/browse/DBCP-413 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Mark W Priority: Minor While using the MS SQL 2012 jdbc drivers with dbcp, I noticed that if you create a connection, then create a preparedStatement from that connection, and close the connection object, PreparedStatement.isClosed() will return false, but you will get a SQLException stating the statement has been closed if you attempt to call any of the set or execute methods. From the JDBC spec: Connection.close An application calls the method Connection.close() to indicate that it has finished using a connection. All Statement objects created from a given Connection object will be closed when the close method for the Connection object is called. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (EXEC-85) error running mvn on eclipse
Ramiro Matteoda created EXEC-85: --- Summary: error running mvn on eclipse Key: EXEC-85 URL: https://issues.apache.org/jira/browse/EXEC-85 Project: Commons Exec Issue Type: Bug Reporter: Ramiro Matteoda I am using DefaultExecutor to run maven on my eclipse plugin. If I run the command mvn --version to check maven version on my eclipse on Mac OSX Snow Leopard It work fine, but, if I run it on MAC OSx Maverick it give an error (error=2 ..) command not found or something like that. I can not figure out the problem, In both OSx the maven is installed correct and running mvn --version on a terminal It works. Regards Ramiro -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (COLLECTIONS-513) NullPointerException in SwitchTransformer.transform
[
https://issues.apache.org/jira/browse/COLLECTIONS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved COLLECTIONS-513.
-
Resolution: Invalid
This is not a bug.
The constructor of SwitchTransformer states that the array of predicates must
not contain null values:
{noformat}
* @param predicates array of predicates, cloned, no nulls
{noformat}
but the provided array of predicates is an array with one null value.
I think the way these tests are created are flawed:
{noformat}
org.apache.commons.collections4.set.CompositeSet var1 = new
org.apache.commons.collections4.set.CompositeSet(
var0);
org.apache.commons.collections4.functors.UniquePredicate var2 = new
org.apache.commons.collections4.functors.UniquePredicate();
org.apache.commons.collections4.Predicate[] var3 = new
org.apache.commons.collections4.Predicate[] { var2 };
java.lang.Object[] var4 = var1.toArray((java.lang.Object[]) var3);
{noformat}
Here var1 is an empty set, whose contents are copied into an object array var4.
But the toArray() method is called with an non-empty array, which will be
modified by the toArray() call and result in this 1-element array with a null
value.
I fail to see what this tries to test, as the result of this operation will be
in any case wrong
NullPointerException in SwitchTransformer.transform
---
Key: COLLECTIONS-513
URL: https://issues.apache.org/jira/browse/COLLECTIONS-513
Project: Commons Collections
Issue Type: Bug
Components: Functor
Affects Versions: 4.0
Environment: Mac OS 10.9, Java 6 and Java 7
Reporter: Cyrille Artho
Attachments: BugReport2.java
A relatively complex test case generated by Randoop results in a
NullPointerException in SwitchTransformer.transform.
I'm not sure if this is an incorrect usage of the method, or if it is a real
bug.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COLLECTIONS-516) NullPointerException in MapUtils.toProperties
[ https://issues.apache.org/jira/browse/COLLECTIONS-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13965813#comment-13965813 ] Thomas Neidhart commented on COLLECTIONS-516: - The javadoc comment refers to the case when the provided map is null, not individual entries within the map. We could add a check to prevent adding null keys to the Properties object, but I think this would just hide wrong usage, so I would prefer to add additional clarification to the javadoc that null keys / values will result in a NullPointerException. NullPointerException in MapUtils.toProperties - Key: COLLECTIONS-516 URL: https://issues.apache.org/jira/browse/COLLECTIONS-516 Project: Commons Collections Issue Type: Bug Components: Collection Affects Versions: 4.0 Environment: Mac OS 10.9, Java 6 Reporter: Cyrille Artho Attachments: Report4.java calling MapUtils.toProperties with a map having null entries results in a NullPointerException. In this case the Map has only entry null, null. However, javadoc states A null input will return an empty properties object. so (1) this should be clarified as it would only apply to the map reference itself, not its contents, or (2) an empty property object should be generated for null entries in the map as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (COLLECTIONS-515) ClassCastException in LazySortedMap when used with equals/transformers
[
https://issues.apache.org/jira/browse/COLLECTIONS-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved COLLECTIONS-515.
-
Resolution: Invalid
There is no surprise here to get a ClassCastException as you provide a wrong
key to the tailMap() method.
{noformat}
org.apache.commons.collections4.trie.PatriciaTrie var0 = new
org.apache.commons.collections4.trie.PatriciaTrie();
org.apache.commons.collections4.Transformer var1 =
org.apache.commons.collections4.functors.ExceptionTransformer.exceptionTransformer();
java.util.SortedMap var2 =
org.apache.commons.collections4.MapUtils.lazySortedMap((java.util.SortedMap)var0,
(org.apache.commons.collections4.Transformer)var1);
java.util.SortedMap var3 = var2.tailMap((java.lang.Object)var2);
{noformat}
So var2 is a PatriciaTrie, and you try to construct a tailMap with the trie
itself as key. Of course this will result in a ClassCastException, the only
surprise here is that it is not thrown immediately.
Trying the same with a java.util.TreeMap will throw the ClassCastException
immediately during the call to tailMap.
ClassCastException in LazySortedMap when used with equals/transformers
--
Key: COLLECTIONS-515
URL: https://issues.apache.org/jira/browse/COLLECTIONS-515
Project: Commons Collections
Issue Type: Bug
Components: Collection, Map
Affects Versions: 4.0
Environment: Mac OS 10.9, Java 6
Reporter: Cyrille Artho
Attachments: Report3.java
When LazySortedMap is used by equals, the result is
java.lang.ClassCastException:
org.apache.commons.collections4.map.LazySortedMap cannot be cast to
java.lang.String
This seems to be odd, as the use of the different transformations should not
result in internal casting to String. See the attached unit test to reproduce.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (COLLECTIONS-514) NullPointerException in MapBackedSet.mapBackedSet
[
https://issues.apache.org/jira/browse/COLLECTIONS-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved COLLECTIONS-514.
-
Resolution: Invalid
The use TreeBag states that it uses a TreeMap as underlying data structure,
this the same limitations apply as for a TreeMap.
In fact I consider this even a bug in the jdk, as the TreeMap states that
adding a mapping with a null key and natural ordering will result in a
NullPointerException, although it does not immediately, only when you try to
get the entry with a null key:
{noformat}
SortedMapString, String map = new TreeMapString, String();
map.put(null, null);
System.out.println(map.get(null));
{noformat}
The NullPointerException is only thrown in the call to get().
NullPointerException in MapBackedSet.mapBackedSet
-
Key: COLLECTIONS-514
URL: https://issues.apache.org/jira/browse/COLLECTIONS-514
Project: Commons Collections
Issue Type: Bug
Components: Bag, Collection, Set
Affects Versions: 4.0
Environment: MacOS 10.9, Java 6
Reporter: Cyrille Artho
Attachments: Report2.java
It seems that addAll has issues with adding a set that is backed by a
singleton map with entry null - null. However, the javadoc of the involved
classes does not state that null entries are disallowed.
Either the code should allow adding a null entry to a bag, or the
documentation should state that null entries are not allowed.
See the attached unit test in JUnit format to reproduce the problem.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COLLECTIONS-512) equals/hashCode mismatch
[ https://issues.apache.org/jira/browse/COLLECTIONS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13965911#comment-13965911 ] Thomas Neidhart commented on COLLECTIONS-512: - Fixed the issue with the TransformingComparator in r1586477. equals/hashCode mismatch Key: COLLECTIONS-512 URL: https://issues.apache.org/jira/browse/COLLECTIONS-512 Project: Commons Collections Issue Type: Bug Components: Collection, Comparator Affects Versions: 4.0 Environment: Mac OS 10.9, Java 6 and Java 7 Reporter: Cyrille Artho Attachments: BugReport1.java, BugReport1_1.java We used Randoop on the collection classes, which found several test cases where two objects are equal but their hash code differs. I will attach a file containing two test cases that are different; the other tests seem to be longer versions showing the same issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (COMPRESS-272) CompressorStreamFactory fails to autodetect files using Unix compress (.Z files)
Paul Blizniak created COMPRESS-272: -- Summary: CompressorStreamFactory fails to autodetect files using Unix compress (.Z files) Key: COMPRESS-272 URL: https://issues.apache.org/jira/browse/COMPRESS-272 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.7 Reporter: Paul Blizniak Priority: Minor I use the factory classes quite extensively to guess the correct implementation of a file that needs to be unpacked. The current doc does list that for lzma and 7zip files, the auto detect will not work. I have worked around this by looking at the file extension, and hope that its correct. For .Z files, I can only uncompress the file if I explicitly tell the factory that its using .Z compression, the auto detect never works. I'm using 1.7, but I dont think its fixed in 1.8 either (after looking at the bug fix list). Either its a bug in the doc, or in the auto detect of the compressor factory. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COLLECTIONS-512) equals/hashCode mismatch
[ https://issues.apache.org/jira/browse/COLLECTIONS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13965925#comment-13965925 ] Thomas Neidhart commented on COLLECTIONS-512: - The same wrong statement is also used in FixedOrderComparator, so this might be affected too. equals/hashCode mismatch Key: COLLECTIONS-512 URL: https://issues.apache.org/jira/browse/COLLECTIONS-512 Project: Commons Collections Issue Type: Bug Components: Collection, Comparator Affects Versions: 4.0 Environment: Mac OS 10.9, Java 6 and Java 7 Reporter: Cyrille Artho Attachments: BugReport1.java, BugReport1_1.java We used Randoop on the collection classes, which found several test cases where two objects are equal but their hash code differs. I will attach a file containing two test cases that are different; the other tests seem to be longer versions showing the same issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COLLECTIONS-516) NullPointerException in MapUtils.toProperties
[ https://issues.apache.org/jira/browse/COLLECTIONS-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13965976#comment-13965976 ] Cyrille Artho commented on COLLECTIONS-516: --- Thank you for commenting on this. Based on your opinion, I agree that a minor change in the javadoc comment is probably best. Maybe: Entries in the map must be non-null. If a null reference is given for the map, this method will return an empty properties object. NullPointerException in MapUtils.toProperties - Key: COLLECTIONS-516 URL: https://issues.apache.org/jira/browse/COLLECTIONS-516 Project: Commons Collections Issue Type: Bug Components: Collection Affects Versions: 4.0 Environment: Mac OS 10.9, Java 6 Reporter: Cyrille Artho Attachments: Report4.java calling MapUtils.toProperties with a map having null entries results in a NullPointerException. In this case the Map has only entry null, null. However, javadoc states A null input will return an empty properties object. so (1) this should be clarified as it would only apply to the map reference itself, not its contents, or (2) an empty property object should be generated for null entries in the map as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COLLECTIONS-513) NullPointerException in SwitchTransformer.transform
[ https://issues.apache.org/jira/browse/COLLECTIONS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13965982#comment-13965982 ] Cyrille Artho commented on COLLECTIONS-513: --- Thank you for confirming this as a false positive. Basically the tool we use generates random sequences of method calls. Parameters have valid types but may not always fulfill other requirements (entries being non-null, for example). We have filtered out other (simpler) cases ourselves from the bug reports, but we were not sure about this one. NullPointerException in SwitchTransformer.transform --- Key: COLLECTIONS-513 URL: https://issues.apache.org/jira/browse/COLLECTIONS-513 Project: Commons Collections Issue Type: Bug Components: Functor Affects Versions: 4.0 Environment: Mac OS 10.9, Java 6 and Java 7 Reporter: Cyrille Artho Attachments: BugReport2.java A relatively complex test case generated by Randoop results in a NullPointerException in SwitchTransformer.transform. I'm not sure if this is an incorrect usage of the method, or if it is a real bug. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COMPRESS-273) NullPointerException when creation fields/entries from scratch
[ https://issues.apache.org/jira/browse/COMPRESS-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cyrille Artho updated COMPRESS-273: --- Attachment: RandoopTest.java NullPointerException when creation fields/entries from scratch -- Key: COMPRESS-273 URL: https://issues.apache.org/jira/browse/COMPRESS-273 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.8 Environment: Mac OS 10.9, Java 6 and 7 Reporter: Cyrille Artho Attachments: RandoopTest.java The API has public default constructors for many data types. However, when these 0-argument constructors are used, certain internal references are null, resulting in a NullPointerException soon after. This also applies to some 1-argument constructors where two references should be set before get... is used later. Either (1) these constructors should be non-public, (2) there should be documentation that certain fields need to be set later for an instance to be usable. In the latter case, there must be public set methods for the missing data. The attachment contains a number of similar test cases that show the same issue in a couple of classes. An example: org.apache.commons.compress.archivers.zip.UnicodeCommentExtraField var0 = new org.apache.commons.compress.archivers.zip.UnicodeCommentExtraField(); org.apache.commons.compress.archivers.zip.ZipShort var1 = var0.getLocalFileDataLength(); -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (COMPRESS-273) NullPointerException when creation fields/entries from scratch
Cyrille Artho created COMPRESS-273: -- Summary: NullPointerException when creation fields/entries from scratch Key: COMPRESS-273 URL: https://issues.apache.org/jira/browse/COMPRESS-273 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.8 Environment: Mac OS 10.9, Java 6 and 7 Reporter: Cyrille Artho Attachments: RandoopTest.java The API has public default constructors for many data types. However, when these 0-argument constructors are used, certain internal references are null, resulting in a NullPointerException soon after. This also applies to some 1-argument constructors where two references should be set before get... is used later. Either (1) these constructors should be non-public, (2) there should be documentation that certain fields need to be set later for an instance to be usable. In the latter case, there must be public set methods for the missing data. The attachment contains a number of similar test cases that show the same issue in a couple of classes. An example: org.apache.commons.compress.archivers.zip.UnicodeCommentExtraField var0 = new org.apache.commons.compress.archivers.zip.UnicodeCommentExtraField(); org.apache.commons.compress.archivers.zip.ZipShort var1 = var0.getLocalFileDataLength(); -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (COMPRESS-274) NullPointerException in ChangeSet.addDeletion when using bogus data
Cyrille Artho created COMPRESS-274: -- Summary: NullPointerException in ChangeSet.addDeletion when using bogus data Key: COMPRESS-274 URL: https://issues.apache.org/jira/browse/COMPRESS-274 Project: Commons Compress Issue Type: Bug Components: Changesets Affects Versions: 1.8 Environment: Mac OS 10.9 with Java 6, 7 Reporter: Cyrille Artho Attachments: Report3.java When adding some bogus data and then trying to call deleteDir with a bogus name, a NullPointerException results. See attached test. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COMPRESS-274) NullPointerException in ChangeSet.addDeletion when using bogus data
[ https://issues.apache.org/jira/browse/COMPRESS-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cyrille Artho updated COMPRESS-274: --- Attachment: Report3.java NullPointerException in ChangeSet.addDeletion when using bogus data --- Key: COMPRESS-274 URL: https://issues.apache.org/jira/browse/COMPRESS-274 Project: Commons Compress Issue Type: Bug Components: Changesets Affects Versions: 1.8 Environment: Mac OS 10.9 with Java 6, 7 Reporter: Cyrille Artho Attachments: Report3.java When adding some bogus data and then trying to call deleteDir with a bogus name, a NullPointerException results. See attached test. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (COMPRESS-275) Packing problem? NoClassDefFoundError: org/tukaani/xz/FilterOptions
Cyrille Artho created COMPRESS-275: -- Summary: Packing problem? NoClassDefFoundError: org/tukaani/xz/FilterOptions Key: COMPRESS-275 URL: https://issues.apache.org/jira/browse/COMPRESS-275 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.8 Environment: Mac OS 10.9 w/ Java 6, 7 Reporter: Cyrille Artho Attachments: Report2.java I can compile the code but not execute it because a class seems to be missing. I guess the class is not part of the API but used internally. It's at least not immediately obvious that other .jar files are required to use some of the functionality. Maybe this was intended to be included in the distribution? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COMPRESS-275) Packing problem? NoClassDefFoundError: org/tukaani/xz/FilterOptions
[ https://issues.apache.org/jira/browse/COMPRESS-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cyrille Artho updated COMPRESS-275: --- Attachment: Report2.java Packing problem? NoClassDefFoundError: org/tukaani/xz/FilterOptions --- Key: COMPRESS-275 URL: https://issues.apache.org/jira/browse/COMPRESS-275 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.8 Environment: Mac OS 10.9 w/ Java 6, 7 Reporter: Cyrille Artho Attachments: Report2.java I can compile the code but not execute it because a class seems to be missing. I guess the class is not part of the API but used internally. It's at least not immediately obvious that other .jar files are required to use some of the functionality. Maybe this was intended to be included in the distribution? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COMPRESS-275) Packing problem? NoClassDefFoundError: org/tukaani/xz/FilterOptions
[ https://issues.apache.org/jira/browse/COMPRESS-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cyrille Artho updated COMPRESS-275: --- Description: I can compile the code but not execute it because a class seems to be missing. I guess the class is not part of the API but used internally. When I use the constructor of org.apache.commons.compress.compressors.xz.XZCompressorOutputStream, then I need org/tukaani/xz/FilterOptions at run-time, which is not part of apache-compress.jar. It's at least not immediately obvious that other .jar files are required to use some of the functionality. Maybe this was intended to be included in the distribution? was: I can compile the code but not execute it because a class seems to be missing. I guess the class is not part of the API but used internally. It's at least not immediately obvious that other .jar files are required to use some of the functionality. Maybe this was intended to be included in the distribution? Packing problem? NoClassDefFoundError: org/tukaani/xz/FilterOptions --- Key: COMPRESS-275 URL: https://issues.apache.org/jira/browse/COMPRESS-275 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.8 Environment: Mac OS 10.9 w/ Java 6, 7 Reporter: Cyrille Artho Attachments: Report2.java I can compile the code but not execute it because a class seems to be missing. I guess the class is not part of the API but used internally. When I use the constructor of org.apache.commons.compress.compressors.xz.XZCompressorOutputStream, then I need org/tukaani/xz/FilterOptions at run-time, which is not part of apache-compress.jar. It's at least not immediately obvious that other .jar files are required to use some of the functionality. Maybe this was intended to be included in the distribution? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COMPRESS-276) NullPointerException in ZipArchiveOutputStream with invalid entries
[ https://issues.apache.org/jira/browse/COMPRESS-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cyrille Artho updated COMPRESS-276: --- Attachment: Report1.java NullPointerException in ZipArchiveOutputStream with invalid entries --- Key: COMPRESS-276 URL: https://issues.apache.org/jira/browse/COMPRESS-276 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.8 Environment: Mac OS 10.9, Java 6, 7 Reporter: Cyrille Artho Attachments: Report1.java Writing raw data seems to cause problems in multiple ways, because an internal field is not set. Is this a wrong API usage? java.io.ByteArrayOutputStream var0 = new java.io.ByteArrayOutputStream(); org.apache.commons.compress.archivers.jar.JarArchiveOutputStream var1 = new org.apache.commons.compress.archivers.jar.JarArchiveOutputStream((java.io.OutputStream)var0); var1.write(25843); Other tests (see attachment) are very similar and cause the same problem. They can probably be ignored because the first test is the shortest one. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (COMPRESS-276) NullPointerException in ZipArchiveOutputStream with invalid entries
Cyrille Artho created COMPRESS-276: -- Summary: NullPointerException in ZipArchiveOutputStream with invalid entries Key: COMPRESS-276 URL: https://issues.apache.org/jira/browse/COMPRESS-276 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.8 Environment: Mac OS 10.9, Java 6, 7 Reporter: Cyrille Artho Attachments: Report1.java Writing raw data seems to cause problems in multiple ways, because an internal field is not set. Is this a wrong API usage? java.io.ByteArrayOutputStream var0 = new java.io.ByteArrayOutputStream(); org.apache.commons.compress.archivers.jar.JarArchiveOutputStream var1 = new org.apache.commons.compress.archivers.jar.JarArchiveOutputStream((java.io.OutputStream)var0); var1.write(25843); Other tests (see attachment) are very similar and cause the same problem. They can probably be ignored because the first test is the shortest one. -- This message was sent by Atlassian JIRA (v6.2#6252)
