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
