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

Jonathan Gibbons jonathan.gibbons at oracle.com
Thu May 7 14:33:06 UTC 2020


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


More information about the javadoc-dev mailing list