> 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.gibb...@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 > >
