RFR - 8132734: java.util.jar.* changes to support multi-release jar files
paul.sandoz at oracle.com
Fri Jan 22 09:26:44 UTC 2016
> On 22 Jan 2016, at 01:39, Mandy Chung <mandy.chung at oracle.com> wrote:
>> On Jan 21, 2016, at 3:49 PM, Steve Drach <steve.drach at oracle.com> 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.
>> 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.
> I only started looking at some files on the webrev. Release._9 catches my attention too and it looks very odd. I think RELEASE_9 is a much better constant name than _9.
While there is a some naming activity over what to call such constants, i think the use a ‘_’ as the first character of a public API artefact should be strongly discouraged, such usages are more commonly associated with internal artefacts or generated code and using such a style for public artefacts sets a “bad" precedence IMO (first use in the Java APIs AFAICT). There needs to be a really strong justification for such public use and at the moment i don’t see one here.
More information about the core-libs-dev