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

[Dawid Weiss]

> Now, given the availability of NIO and zipfs as a standard filesystem provider, it would be relatively easy to add support for writing into zip files.

Indeed, it's not difficult. I modified the expeirmental code into a
simple wrapper that looks at the suffix of '-d' option's path and
conditionally switches to ZIP filesystem if this seems to point to a
"zip/jar" file. I'll leave it at [1] in case somebody finds it useful.

Dawid

[1] https://github.com/dweiss/javadoc-zip

On Sun, Jul 12, 2020 at 2:58 AM Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
>
>
> On 7/11/20 12:30 PM, Dawid Weiss wrote:
> > Hi Jon,
> >
> >> In this case, it would (probably) be easier for you to just use a
> >> standard StandardFileManager (no subtyping required) and use
> >> the setLocation call to set the DOCUMENTATION_OUTPUT  [...]
> > Ah... Brilliant. You're right - it'd be a much better solution.
> >
> >> At least part of the problem we're dealing with here is that JavaFileManager
> >> was not designed for all of javadoc's needs. (It was designed with javac
> >> in mind, and designed before the NIO file system API was available.)
> > I (and anyone) can see this historical baggage looking at JDK sources.
> > It's still in
> > better shape than it used to be though (where pretty much everything
> > was in proprietary
> > space).
> >
> >> On supporting a ZIP file system, ... "possibly".
> > No pressure. It'd be an esoteric feature, no doubt. But it'd be also a
> > good way to test whether the
> > public API leans towards such use cases. It's surely fun to play with
> > them - I think they're vastly
> > underrated (the doclet API in particular).
> >
> > Dawid
>
> Dawid,
>
> It used to be a relatively difficult feature to add.  Even when NIO was
> added, zipfs was not initially a standard provider. Now, given the
> availability of NIO and zipfs as a standard filesystem provider, it
> would be relatively easy to add support for writing into zip files. But
> the use case for javac has never been very compelling, and so the
> ability to write into zip files has been left to higher level tools.
> But the use case for javadoc is more interesting and somewhat more
> realistic, which raises it up a notch on the wish-list. I suspect the
> hardest part will be figuring out the command-line semantics!
>
> As for the doclet API, it is less important than it used to be, because
> of the availability of alternate modeling APIs when documentation is not
> required ... but taglets are becoming more interesting.  Watch for some
> updates, or at least some specific RFEs being filed in JBS.
>
> -- Jon
>
>