[
https://issues.apache.org/jira/browse/COMPRESS-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17821859#comment-17821859
]
Gary D. Gregory commented on COMPRESS-667:
------------------------------------------
{quote}The current Builder implementation appears to not have convenience
methods for the most common construction scenarios e.g. construction from a
File or Path.
{quote}
It does, look for all callers of {{ZipFile.builder()}} and you'll find plenty
of tests using different input types. For example:
ZipFileTest.testZipWithShortBeginningGarbage():
{code:java}
try (ZipFile zipFile = ZipFile.builder().setPath(path).get()) {
...
}
{code}
Constructors on builders just duplicates part of the problems of constructors
on a domain class; there is always one more "convenience" constructor to add,
and then you're back to ZipFile's fourteen constructors with no end in sight.
> ZipFile Builder lacks convenience constructors for File/Path
> ------------------------------------------------------------
>
> Key: COMPRESS-667
> URL: https://issues.apache.org/jira/browse/COMPRESS-667
> Project: Commons Compress
> Issue Type: Improvement
> Affects Versions: 1.26.0
> Reporter: Daniel Lowe
> Priority: Major
>
> The current Builder implementation appears to not have convenience methods
> for the most common construction scenarios e.g. construction from a File or
> Path.
> As
> {color:#000000}{color:#000000}ZipFile.{color}{color:#000000}builder{color}{color:#000000}().get()
> {color}{color}isn't valid, personally I think the Builder constructor itself
> should require a
> {color:#000000}{color:#000000}SeekableByteChannel/{color}{color}File/Path{color:#000000}{color:#000000}
> {color}{color}
> I tend to agree with Elliotte's comments
> ([https://lists.apache.org/thread/5vtbbs18d4rntn8tpnpsvo0g9h6svc30),] and
> would also see de-deprecating the one argument constructors as a valid
> solution
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
