[
https://issues.apache.org/jira/browse/IO-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17937640#comment-17937640
]
Éamonn McManus commented on IO-866:
-----------------------------------
Unfortunately the [recent
fix|https://github.com/apache/commons-io/commit/7815650ada4f27dc72c8c470d626481282b13dab]
does not work. Google's tests reveal a failure, which I have boiled down to
this repro:
{code:java}
byte[] prefix = new byte[32];
byte[] suffix = new byte[2];
byte[] fileContents = "someTexts".getBytes();
Files.write(testFile.toPath(), fileContents);
byte[] expected = new byte[prefix.length + fileContents.length +
suffix.length];
System.arraycopy(prefix, 0, expected, 0, prefix.length);
System.arraycopy(fileContents, 0, expected, prefix.length,
fileContents.length);
System.arraycopy(suffix, 0, expected, prefix.length +
fileContents.length, suffix.length);
assertTrue(IOUtils.contentEquals(
new ByteArrayInputStream(expected),
new SequenceInputStream(
Collections.enumeration(
Arrays.asList(
new ByteArrayInputStream(prefix),
new FileInputStream(testFile),
new ByteArrayInputStream(suffix)))))); {code}
The assertion passes if I replace the implementation of IOUtils.contentEquals
with a simple loop that reads one byte from each stream until finding a
mismatch or EOF, but it fails with the current snapshot implementation.
This is just my opinion, but the logic of the new
[FileChannels.contentEquals|https://github.com/apache/commons-io/blob/c2e18c6d02f07c7466b29caeb5ac94aa04c4957d/src/main/java/org/apache/commons/io/channels/FileChannels.java#L61]
method seems ferociously complicated and I wonder whether a simpler if less
efficient approach might be better. Perhaps anyway the established
IOUtils.contentEquals method could revert to its [old
implementation|https://github.com/apache/commons-io/blob/1d2019f2a32fc5388e955c5a3a7fa4f236538d4a/src/main/java/org/apache/commons/io/IOUtils.java#L906]?
> Recent change to AbstractByteArrayOutputStream breaks source compatibility
> --------------------------------------------------------------------------
>
> Key: IO-866
> URL: https://issues.apache.org/jira/browse/IO-866
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
> Reporter: Éamonn McManus
> Priority: Major
>
> A [recent
> change|https://github.com/apache/commons-io/commit/b1c3d9d676c39512b7bbe9a02af57bfb2ef3dd15]
> to AbstractByteArrayOutputStream introduced an override of
> `OutputStream.write(byte[])` which removes the `throws IOException` clause
> from the inherited method. That means it is not source-compatible, since Java
> code that calls the method inside a try/catch will no longer compile unless
> something else in the try/catch also throws IOException. This affects at
> least two other Apache projects:
> * Apache POI
> [here|https://github.com/apache/poi/blob/3f4e7189b3190e796d1748fb308849cae0797ec8/poi/src/main/java/org/apache/poi/hssf/record/EscherAggregate.java#L1041]
> * Apache XML Graphics Commons
> [here|https://github.com/apache/xmlgraphics-commons/blob/b662464628a89bee30334bd133ab6387937aa182/src/main/java/org/apache/xmlgraphics/image/loader/impl/ImageLoaderRawJPEG.java#L230]
> It's obviously a bit annoying to force client code to catch `IOException`
> when it can't actually be thrown, but that's how it was before this change so
> the `throws` clause should probably be reinstated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
