[
https://issues.apache.org/jira/browse/COMPRESS-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15990111#comment-15990111
]
Zbynek Vyskovsky edited comment on COMPRESS-390 at 4/30/17 4:01 AM:
--------------------------------------------------------------------
[~bodewig] No problem,I'm sorry about the delay, I haven't found time to go
through it and to think about it into detail...
I see your last point, it would be solvable with Java 8 default methods but we
still maintain Java 7 compatibility, so not an option here anyway.
About the previous comment - I'm just thinking about trade-off between perfect
and never-lying solution and something which is still quite easy to use and is
transparent across all the potential types of archives. One thing I'm not happy
about that proposal is to have different enum for each of the archive types -
that clearly breaks the transparency.
Therefore, I'd rather stick to Gary's proposal, i.e. independent interface that
could be or not implemented by the specific ArchiveEntry. Still it could return
-1 under certain circumstances (bit based stream or whatever exotic format may
be used by one specific file within the archive).
So I'd suggest something like:
{code:java}
interface EntryOffsets {
/** Returns the offset of data stream within the archive file,
OFFSET_UNKNOWN when not known. */
long getDataStreamOffset();
/** Indicates whether the data stream is continuous, i.e. not split
into multiple files, interspersed with control blocks, etc. */
boolean isDataStreamContinuous();
}
{code}
About the other suggestion, whether to put it on the same level as ArchiveEntry
or maybe into the main Archive class, I don't have so strong opinion. I feel
that firstly it would be inconsistent, secondly the methods in Archive class
usually do some big work which is not the case here...
was (Author: kvr):
[~bodewig] No problem,I'm sorry about the delay, I haven't found time togo
through it and to think about it into detail...
I see your last point, it would be solvable with Java 8 default methods but we
still maintain Java 7 compatibility, so not an option here anyway.
About the previous comment - I'm just thinking about trade-off between perfect
and never-lying solution and something which is still quite easy to use and is
transparent across all the potential types of archives. One thing I'm not happy
about that proposal is to have different enum for each of the archive types -
that clearly breaks the transparency.
Therefore, I'd rather stick to Gary's proposal, i.e. independent interface that
could be or not implemented by the specific ArchiveEntry. Still it could return
-1 under certain circumstances (bit based stream or whatever exotic format may
be used by one specific file within the archive).
So I'd suggest something like:
{code:java}
interface EntryOffsets {
/** Returns the offset of data stream within the archive file,
OFFSET_UNKNOWN when not known. */
long getDataStreamOffset();
/** Indicates whether the data stream is continuous, i.e. not split
into multiple files, interspersed with control blocks, etc. */
boolean isDataStreamContinuous();
}
{code}
About the other suggestion, whether to put it on the same level as ArchiveEntry
or maybe into the main Archive class, I don't have so strong opinion. I feel
that firstly it would be inconsistent, secondly the methods in Archive class
usually do some big work which is not the case here...
> Expose zip stream offset and size via API
> -----------------------------------------
>
> Key: COMPRESS-390
> URL: https://issues.apache.org/jira/browse/COMPRESS-390
> Project: Commons Compress
> Issue Type: New Feature
> Components: Archivers
> Affects Versions: 1.13
> Reporter: Zbynek Vyskovsky
> Labels: features, github-import, patch
> Fix For: 1.14
>
>
> In certain cases it may be useful to get information about where in the
> archive the stream starts and ends. Typically when zip is used as resource
> container and the resources are then mapped directly into memory, but not
> only.
> The size and compressed size are already available but not the stream offset.
> This can be applied to other archive types as well, therefore it would make
> sense to put this into basic interface - ArchiveEntry. But not necessarily
> all of them have to support it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
