javadoc ignores -XD-Xmaxerrs

Jonathan Gibbons jonathan.gibbons at oracle.com
Wed Jun 9 16:40:49 PDT 2010


On 06/04/2010 06:07 PM, Martin Buchholz wrote:
> Hi javadoc team,
>
> This is a bug report with proposed fix.
>
> We have reason to believe that javadoc was designed
> to accept javac flags like -Xmaxerrs via
>
> javadoc -XD-Xmaxerrs=NNNN ....
>
> However,
>
> this is not documented, except via 'javac -X'
> javadoc should also really have a -X flag
> that documents its "nonstandard" -Xxxx flags.
>
> The -XD-Xmaxerrs=NNNN flag is not recognized
> because the Messager in
> src/share/classes/com/sun/tools/javadoc/Start.java
> is created before the options are parsed.
>
> Here's a fix that works for us, but it seems likely that
> there is an architecturally cleaner fix:
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/javadoc-Xmaxerrs/
>
> Martin
>    

Martin,

What are you trying to achieve with your proposed fix (beyond the 
initialization order problem), and does it actually have the effect you 
expected?

I believe your proposed fix as-is is subject to NPE for those cases 
where the messager is required before you initialize it. That's not a 
big deal; I've got a somewhat cleaner fix, as regards the initialization 
issues.   But setting -XD-Xmaxerrs only affects the javac part of 
javadoc; it seems that javadoc can generate an unbounded number of 
errors and warnings while generating the docs themselves, since the 
javadoc messages are reported via different methods that are not subject 
to the limits.

I'm looking at providing -Xmaxerrs and -Xmaxwarns for javadoc. I think 
these values should encompass all the messages that may be generated 
(i.e. from both javac and javadoc, because anything else is silly) but 
that leaves a question of what the default limit should be -- 100, as is 
the standard for javac, or unbounded, as is (sort-of) the case for javadoc.

-- Jon



More information about the compiler-dev mailing list