RFR - 8132734: java.util.jar.* changes to support multi-release jar files
Paul Sandoz
paul.sandoz at oracle.com
Fri Jan 29 17:39:48 UTC 2016
> On 29 Jan 2016, at 18:27, Steve Drach <steve.drach at oracle.com> 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.
More information about the core-libs-dev
mailing list