[ 
https://issues.apache.org/jira/browse/COMPRESS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16466089#comment-16466089
 ] 

Stefan Bodewig edited comment on COMPRESS-452 at 5/7/18 4:12 PM:
-----------------------------------------------------------------

japicmp doesn't see any breaking change at all, not even a source one. I'd 
blame this on japicmp :-) I haven't been able to use Clirr on Compress for a 
while now, the details are escaping me.
As for binary compatibility I'm pretty sure the constructor signature seen by 
the compiler will be used. Method dispatch does most of its magic at compile 
time and at runtime only looks for the most derived class that provides the 
signature. In the case of constructors there is no derived class to look into 
at all.


was (Author: bodewig):
japicmp doesn't see any breaking change at all, not even a source one. I'd 
blame this i´n japicmp :-) I haven't been able to use Clirr on Compress for a 
while now, the details are escaping me.
As for binary compatibility I'm pretty sure the constructor signature seen by 
the compiler will be used. Method dispatch does most of its magic at compile 
time and at runtime only looks for the most derived class that provides the 
signature. In the case of constructors there is no derived class to look into 
at all.

> "Stream is not in the BZip2 format" exception on valid archive
> --------------------------------------------------------------
>
>                 Key: COMPRESS-452
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-452
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers, Compressors
>    Affects Versions: 1.16.1
>            Reporter: Tomisław Kityński
>            Priority: Major
>         Attachments: txt.7z
>
>
> The included 7z archive (with only one file), that is password protected, can 
> be properly decompressed with 7z tool. Yet, getNextEntry() throws "Stream is 
> not in the BZip2 format" exception.
> The code is:
> {code:java}
> private static final byte[] PASSWORD = "iBlm8NTigvru0Jr0".getBytes();
> public static void main(String[] args) throws IOException {
>  String fileName = "r:/txt.7z";
>      SevenZArchiveEntry entry;
>      try (SevenZFile arch = new SevenZFile(new File(fileName), PASSWORD)) {
>  while ((entry = arch.getNextEntry()) != null) 
> {             System.out.println(entry.getName()); }
> }
> {code}
> The same exception is thrown when one uses SevenZFile(SeekableByteChannel, 
> byte[]) constructor. Password seems to be OK, since changing it yields 
> different exception (and it also works in 7z tool).
> Full exception is:
> {noformat}
> Exception in thread "main" java.io.IOException: Stream is not in the BZip2 
> format
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:252)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.<init>(BZip2CompressorInputStream.java:134)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.<init>(BZip2CompressorInputStream.java:112)
>   at 
> org.apache.commons.compress.archivers.sevenz.Coders$BZIP2Decoder.decode(Coders.java:254)
>   at 
> org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:79)
>   at 
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:933)
>   at 
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:909)
>   at 
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:222)
>   at UnpackTest.main(UnpackTest.java:17)
> {noformat}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to