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

[Alan Bateman]

On 21/01/2016 18:02, Steve Drach wrote:
> :
> 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.

> :
> 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.

> :
>> 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.


> :
> 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.

-Alan