Your observation is well-founded.
The use of javac OptionKind is merely a convenience, and not inherently
required as part of interacting with javac's option mechanism. It can
be replaced by a similar, local enum in ToolOption.
I could envisage a world in which javac's Option enum is split into an
interface and an enum which implements that interface. Then, javadoc
could also implement that interface instead of defining the ToolOption
interface. That would also allow us to directly include javac Option
objects in the list of javadoc Option objects, instead of using proxy
objects that delegate.
However, that would tighten the connection between javadoc and javac,
and I'm not sure that is a direction in which we want to go. Demeter
would not probably not approve.
-- Jon
On 01/24/2020 09:36 AM, Pavel Rappo wrote:
I was definitely not suggesting that! Rather, I was commenting on what I saw.
The state of affairs, that predate your changeset.
On 24 Jan 2020, at 17:29, Jonathan Gibbons <[email protected]> wrote:
Changing all this (especially javac!) is more than I wanted to do in this
changeset!
