RFR - 8132734: java.util.jar.* changes to support multi-release jar files
Alan.Bateman at oracle.com
Thu Jan 21 19:37:56 UTC 2016
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
> 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.
More information about the core-libs-dev