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