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
