> On 29 Jan 2016, at 18:27, Steve Drach <[email protected]> wrote:
>>
>> This may have come up before but JarFile has two sets of constructors, one
>> takes the file path as a String, the other as a File. I just wondering about
>> introduce a second constructor so that they match.
>
> We felt that one constructor was sufficient on the theory that it’s use will
> be infrequent, at least initially. And it’s easy to map a String to a File.
>
Right, my preference is to stick to one for the moment and add another later if
really needed.
>>
>> One other thing that I've been wondering about is the stream() and entries()
>> methods. Has there been any discussion about these doing filter?
>
> Not that I’m aware of.
>
>> Maybe it is too expensive and best left to the user of the API? Part of the
>> context for asking is modular JARs of course.
>
> Perhaps you can elaborate.
Alan’s point is that traversing using entries()/stream() always returns the
versioned entries (if any) rather than all entries, thus in a sense filters.
My assumption was the traversal should by default be consistent with a calls to
getEntry, thus:
jarFile.stream().forEach(e -> {
JarEntry je = jarFile.getJarEntry(e.getName());
assert e.equals(je);
});
There might need to be another stream method that returns all entries.
Paul.
