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