RFR: 8320234: Merge doclint.Env.AccessKind with tool.AccessKind

[Pavel Rappo]

On Mon, 20 Nov 2023 17:13:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>>> For better or worse, every enum exposes its constants' declaration order. That order may unexpectedly become relied upon elsewhere, and the author of the enum cannot do anything about it. T
>> 
>> Since any `enum` implements `Comparable`, it is not reasonable to say that the order may be relied on "unexpectedly".  It is an intentionally defined feature of the language design.   And the author _can_ do something about it: the author can choose not to reorder constants when the order is significant.
>> 
>> A more interesting design, back in the day, might have been to make `Comparable` an opt-in super type, but that's 20-20 hindsight and not the case.
>
> While it is not _necessary_ to indicate that an enum implements `Comparable`, it is permissible to state it explicitly, such as in `enum Foo implements Comparable<Foo> { foo1, foo2 }`.  which is a somewhat more linguistic way of writing `/** The order of the constants is important. */ enum Foo { foo1, foo2 }`

> Since any `enum` implements `Comparable`, it is not reasonable to say that the order may be relied on "unexpectedly".

What I mean is that not every enum client uses `compareTo()` or `values()[0]` and `values()[values().length - 1]` to get the opposite extremes of a certain enum class. Not every client uses `EnumSet.range`. However, given enough time, they likely, eventually will.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16714#discussion_r1399519679