RFR: JDK-8237803 Reorganize impl of tool options

[Jonathan Gibbons]

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 <jonathan.gibbons at oracle.com> wrote:
>>
>> Changing all this (especially javac!) is more than I wanted to do in this changeset!