Sherman, thanks for your consideration. Am 31.05.2016 um 19:08 schrieb Xueming Shen:
Yes, not for a single use case. But I was wondering, that such method is not part of StringBuilder since long, as I could think about many use cases.Ulf, thanks for the suggestions!On 5/31/16 6:27 AM, Ulf Zibis wrote:Hi Sherman, 1.) wouldn't it be better to have a public getBytes() in AbstractStringBuilder? Then you could save the array copy with sb.toString() here:One single use case here probably is not a strong enough reason to add such a utility method into ASB.
I was hesitated to exposure zfs.zc to be package private for some reason, that was why have the pair of zfs.getBytes/String(). But sure I can do it if it makes the communication clearer.
Yes fine, and it saves method parameters to be passed. I'm also wondering, why ZipCoder isn't a sub class of j.n.c.Charset
6.) Avoid String instatiation especially when called from child paths iterator *loop*.This can be a candidate for further optimization.
Yes.
Currently my assumption is that non-utf8 jar/zip files are not the main use cases for zipfs (assume most of them are the result of either the jar tool or j.u.zip apis),
Is this the answer to my # 3.) ?I really often see Windows-1252 coded zip files for download in the web. Maybe you see them rarely as american, but if there are german Umlaute in the file names, it' really painful to convert all the paths here on UTF-8 Linux.
And I still think, moving the string concatenation to ZipPath constructor would be a good idea. I believe, this would make things more simple and less redundant:
ZipPath(ZipFileSystem zfs, String first, String... more)
Thanks,
-Ulf
