RFR: JDK-8237803 Reorganize impl of tool options
jonathan.gibbons at oracle.com
Fri Jan 24 18:32:14 UTC 2020
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.
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!
More information about the javadoc-dev