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

[Dawid Weiss]

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