[
https://issues.apache.org/jira/browse/COMPRESS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15008283#comment-15008283
]
Stefan Bodewig commented on COMPRESS-327:
-----------------------------------------
The comment is going to be almost completely off-topic for the issue at hand.
The only relevant bit: The main problem is that {{SeekableInputStream}}
requires Java7 which might make the next release incompatible enough with 1.10
to warrant a new major release (officially Compress 1.x supports Java5).
[~damjan] I don't remember seeing you post to the dev list, must have missed it
(or it never reached the list?).
The 2.x branch
https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=shortlog;h=refs/heads/compress-2.0
is stalled more than abandoned, I'm not sure this makes a difference, though.
IMHO the ideas are viable but I've run out of time (or rather spent my OSS time
slices elsewhere). It would be a lot easier to find motivation picking it up
again if other people would join.
> Support in-memory processing for ZipFile
> ----------------------------------------
>
> Key: COMPRESS-327
> URL: https://issues.apache.org/jira/browse/COMPRESS-327
> Project: Commons Compress
> Issue Type: New Feature
> Reporter: Brett Kail
> Priority: Minor
> Attachments: seekable-input-stream.txt
>
>
> ZipFile (and SevenZFile) currently require a File argument, but it would be
> nice to support in-memory byte buffers rather than requiring temp files.
> Perhaps create a new SeekableInputStream class (or SeekableDataInput
> interface) and add corresponding constructors.
> For convenience, perhaps also add a utility class that wraps a ByteBuffer
> and/or byte[] and implements the new interface.
> (The sevenz package appears to have a similar limitation, so it might make
> sense to add the support there at the same time, but I personally don't have
> a need for that.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
