JDK-8150130 : NPE building javafx docs with new doclet
  • Type: Bug
  • Component: tools
  • Sub-Component: javadoc(tool)
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2016-02-18
  • Updated: 2016-03-16
  • Resolved: 2016-03-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b109Fixed
Related Reports
Blocks :  
JDK-8149964 - Update FX 9 boot JDK to JDK 9
Relates :  
JDK-8090255 - Fix doclint errors and warnings in JavaFX API docs
Description
We are trying to build JavaFX with JDK 9, and the new doclet is getting an NPE while generating our docs.

javadoc: error - jdk.javadoc.internal.doclets.toolkit.util.DocletAbortException: java.lang.NullPointerException

I have attached the log file and the javadoc.options file that is used.
Comments
Is this bug fix going to make this week's build?
29-02-2016
So the real root cause is the null here, in DocTreeMaker. /* * Primarily to produce a DocCommenTree when given a * first sentence and a body, this is useful, in cases * where the trees are being synthesized by a tool. */ @Override @DefinedBy(Api.COMPILER_TREE) public DCDocComment newDocCommentTree(List<? extends DocTree> firstSentence, List<? extends DocTree> body, List<? extends DocTree> tags) { ListBuffer<DCTree> lb = new ListBuffer<>(); lb.addAll(cast(firstSentence)); lb.addAll(cast(body)); List<DCTree> fullBody = lb.toList(); DCDocComment tree = new DCDocComment(null, fullBody, cast(firstSentence), cast(body), cast(tags)); return tree; } Instead of passing null, you could pass in a synthetic Comment, created locally as an anon inner class, that provides default behavior, including returning NOPOS for getSourcePos.
19-02-2016
Noted on the NOPOS. Created here via DocTreeFactory. http://hg.openjdk.java.net/jdk9/dev/langtools/file/b14765617d7f/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java#l193 Called by: MemberSummaryBuilder::processProperty(....)
19-02-2016
Although a sourcePosition and a lineNumber are both integer-valued concepts, they are not the same, so using hetLineNumber to fulfill getSourcePosition is wrong. If you want to go that route, the correct way would be "return NOPOS;" or "return Position.NOPOS;" Where are you creating the synthetic trees, with a null comment field?
19-02-2016
com.sun.media.jfxmedia.effects is an internal package that will be on the classpath with a full FX build. We should not refer to implementation classes in our public docs, though, so I will file a bug on this.
19-02-2016
A possible fix (not final! I need to discuss this with the team) diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java @@ -64,6 +64,9 @@ public int pos; public long getSourcePosition(DCDocComment dc) { + if (dc.comment == null) { + return DiagnosticSource.NO_SOURCE.getLineNumber(pos); + } return dc.comment.getSourcePos(pos); } Are these forward references ? or because I don't have these on the classpath ? Generating /tmp/ksrini/javafx-out/javafx/scene/media/AudioEqualizer.html... error: package com.sun.media.jfxmedia.effects does not exist error: package com.sun.media.jfxmedia.effects does not exist Generating /tmp/ksrini/javafx-out/javafx/scene/media/EqualizerBand.html... error: package com.sun.media.jfxmedia.effects does not exist error: package com.sun.media.jfxmedia.effects does not exist error: package com.sun.media.jfxmedia.effects does not exist error: package com.sun.media.jfxmedia.effects does not exist
19-02-2016
That makes sense. Thanks for the explanation.
19-02-2016
To explain there are two levels of checking, by doclint, and by the doclet. The doclet not wanting to duplicate diagnostics will suppress its own, iff doclint is active. So the issue with the NPE is when the doclet is trying to emit diagnostics, thus enabling doclint will prevent the NPE from the doclet.
19-02-2016
No, he really did mean remove "-Xdoclint:none" (and yes, it seems counter-intuitive to me that doclint is active with this option). Unfortunately, while that does make the NPE go away, it reveals the reason we use -Xdoclint:none in our build: we get many, many errors without it. We have a bug filed to fix all doclint errors -- JDK-8090255 -- which I just raised to P3 and targeted to JDK 9. We have so many, though, that we still hope to get a fix the javadoc NPE so we can switch to using JDK 9 without having to fix all our docs right away.
19-02-2016
Currently in the javafx/javadoc build script doclint is disabled completely with -Xdoclint:none. In one scenario there are DCErroneous that the HtmlWriter is trying to process, because doclint is off!, it wants to report these errors. But since treeFactory.newDocCommentTree(..) sets comment to be a null, so we get a NPE trying to reference it here: public long getSourcePosition(DCDocComment dc) { return dc.comment.getSourcePos(pos); } As a way to get past this if -Xdoclint:none is removed, the doclint will be active, and will likely prevent the doclet from trying to emit diagnostics, but likely some will escape, such as references. Therein lies the problem, either we stuff in a DCDocComment.comment on creation (DTM) of this DocComment or we take some evasive action trying to get the SourcePosition, such as a NOPOS, if comment is null.
19-02-2016
[~ksrini] remove -Xdoclint:none? Do you mean replace any other -Xdoclint setting with -Xdoclint:none? Or add -Xdoclint:none? I'm surprised that doclint is active in any way if -Xdoclint:none is specified.
19-02-2016
If you remove -Xdoclint:none in your build script the javadoc generation will succeed, without a NPE, the reason is the doclet will not display any diagnostics, if doclint is enabled, however there are many many errors :(. The underlying issue is that there are synthetic DocTrees for setter/getters etc. it is not setup correctly, and the DCDocComment.comment is a null, and this is required to determine the Diagnostic information, I will fix it.
19-02-2016
I took a quick stab at fixing the doclint errors that are (apparently) triggering this bug. I was able to get past the first one, but it still fails on the following file, even when JDK 8 javadoc calls it doclint clean: Generating /localhome/kcr/javafx/9-kcr/jfx/rt/build/javadoc/javafx/scene/control/TableColumn.html... javadoc: error - jdk.javadoc.internal.doclets.toolkit.util.DocletAbortException: java.lang.NullPointerException 1 error 39 warnings
19-02-2016
Steps to reproduce: 1. Clone the JavaFX repo: $ hg clone http://hg.openjdk.java.net/openjfx/9-dev/rt 2. Run javadoc using the attached javadoc2.options file. $ cd rt $ javadoc '@javadoc2.options' I have attached the log file from this run on my machine.
18-02-2016