StandardDoclet requires private DocletEnvironment (due to a cast in WorkArounds)

[Jonathan Gibbons]

Dawid,

I agree that the situation is less than ideal.  The possibility/desire
to subtype the standard doclet and to provide a modified environment
was not anticipated when we wrote the current version of the doclet ...
and even the need for that internal 'WorkArounds' class is less than
ideal, as you might guess from the name.

But, keep asking these questions; it helps us to know how folk are
trying to use tools like javadoc.

-- Jon

On 5/7/20 7:40 AM, Dawid Weiss wrote:
> Thanks Jon. It is a pity there is so little flexibility around the
> standard doclet (or its HTML producer) because rewriting everything
> from scratch is out of question. I'll take a look at getting it to
> work via tool provider - thank you for the hint!
>
> D.
>
> On Thu, May 7, 2020 at 4:33 PM Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>> Dawid,
>>
>> The issue about being difficult to subtype the StandardDoclet is a
>> known issue.
>>
>> You should be able to provide your own file manager if you invoke
>> javadoc via the API available in javax.tools.
>>
>> https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/tools/ToolProvider.html#getSystemDocumentationTool()
>>
>> -- Jon
>>
>>
>> On 5/7/20 1:29 AM, Dawid Weiss wrote:
>>> Hello everyone,
>>>
>>> I had a somewhat wild idea of trying to modify the behavior of the
>>> StandardDoclet to write directly to a ZIP file (instead of the file
>>> system). All the pieces fall into place relatively easily:
>>>
>>> 1) Create a custom Doclet that extends (public) StandardDoclet and
>>> overrides the run method with:
>>>
>>> public boolean run(DocletEnvironment docEnv) {
>>>       return super.run(new CustomEnvironment(docEnv));
>>> }
>>>
>>> 2) CustomEnvironment delegates everything to docEnv except it returns
>>> a ForwardingJavaFileManager over the docEnv.getJavaFileManager with a
>>> bunch of "get*Input" methods substituted.
>>>
>>>
>>> The only problem is - it doesn't work. :) Internally WorkArounds has a
>>> cast to an internal implementation type:
>>>
>>> public WorkArounds(BaseConfiguration configuration) {
>>>       [...]
>>>       this.toolEnv = ((DocEnvImpl)this.configuration.docEnv).toolEnv;
>>> }
>>>
>>> And it's a showstopper (maybe there are others but I didn't have a
>>> chance to try).
>>>
>>> Is there any way forward out of this (or an alternative take I can try)?
>>>
>>> Dawid