RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Steve Drach steve.drach at oracle.com
Thu Jan 21 23:49:09 UTC 2016


>> I suspected this is a bike shed candidate.  I think Release._9 is nicer and it conveys the same information in a less cluttered way than Release.RELEASE_9.
> Yes a bike shed, I'm just saying that Release._9 looks odd/inconsistent when we have SourceVersion.RELEASE_9 elsewhere. Maybe there has been discussion on this topic already. With a static import then RELEASE_9 isn't too bad.

I’ll leave this as an open issue for awhile in case I get another reviewer that feels as strongly about it you do, or as I do.

> 
>> :
>> The entries in a legacy jar (the only entries) or in the unversioned  section of a multi-release jar are directly under the top-most directory
> All I'm saying is that Release.ROOT doesn't feel quite right, esp. when ROOT is defined as the unversioned entries.

How about Release.BASE for base entries?

> 
>> :
>>> I don't have time to do a detailed pass over the updated tests but I wonder if SimpleHttpServer is really a candidate to put in the testlibrary tree. It looks like it is very specific to multi-release JARs and so I would expect to be co-located with those tests rather than being a hazard in the testlibrary tree.
>> It’s in the testlibrary under java/util/jar with the other multi-release specific test “helper” classes.  I could make it even more specific by putting it under a java/util/jar/multi-release directory
> Yes, it needs to move to somewhere specific because it's not general purpose.

I moved it to the same file as the test itself, making it a package-private class

>> Do we really have to stick with 80 column hollerith card semantics?  Even that was changed to 96 columns about 50 years ago.  The one line, other than some “fixmes" that will be removed when JEP 223 is integrated, that exceeds 96 characters long will be changed by wrapping it to 94 columns.
> I didn't mention 80. If you looks at the sdiffs for URLClassPath and JarFile when the outliers should be obvious. All I can suggest is to keep thing consistent with the existing code where possible.

I only found one instance in JarFile and one instance in URLClassPath that seemed too long.  I wrapped them both to be less than 95 columns.  Even for short lines when using sdiff I sometimes need to “left scroll” — not sure that making it sdiff friendly is a reasonable constraint.


More information about the core-libs-dev mailing list