[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Cp-tools-discuss] bug + possible fix (patch) in texidoclet: TreeNode.ja
From: |
Alex Lancaster |
Subject: |
[Cp-tools-discuss] bug + possible fix (patch) in texidoclet: TreeNode.java |
Date: |
21 Feb 2002 01:14:26 -0800 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 |
Julian,
I found another apparent bug in texidoclet when attempting to test
texidoclet with gjdoc. This is a strange one because using the same
doclet (texidoclet) with both Sun's javadoc and gjdoc gives different
errors, but the bug itself seems to be in texidoclet, not gjdoc.
In any case, if I run the following:
jdb -Dgnu.classpath.tools.gjdoc.LogLevel=1 -classpath
"tmp:../tmp:/usr/lib/jdk1.3.1/lib/tools.jar:../cp-tools/texidoclet.jar"
gnu.classpath.tools.gjdoc.Main -doclet
gnu.classpath.tools.doclets.texinfo.Driver gnu.classpath.tools.gjdoc
-sourcepath ../../classpath:. -d doc
[... verbose output skipped...]
Generating .texid files
TexiDoclet creates texinfo source...
Generating TexInfo index
writing file docs/packages
writing file docs/packages.etags
java.lang.reflect.InvocationTargetException: java.lang.NullPointerException
at
gnu.classpath.tools.doclets.texinfo.TreeNode.addTreeEntry(TreeNode.java:184)
at
gnu.classpath.tools.doclets.texinfo.TexiIndex.createIndex(TexiIndex.java:95)
at
gnu.classpath.tools.doclets.texinfo.TexiIndex.main(TexiIndex.java:184) at
gnu.classpath.tools.doclets.texinfo.Driver.start(Driver.java:102)
at java.lang.reflect.Method.invoke(Native Method)
at gnu.classpath.tools.gjdoc.Main.startDoclet(Main.java:607)
at gnu.classpath.tools.gjdoc.Main.start(Main.java:778)
at gnu.classpath.tools.gjdoc.Main.main(Main.java:676)
This can easily be traced to a logic problem in TreeNode.java, in
which it appears that following a test for null on a variable, the
subsequent statement is an operation on that variable.
This is the offending piece of code:
ClassEntry ifaceEntry =
(ClassEntry)interfaceEntries.get(implementedInterfaces[i]);
if (ifaceEntry==null) {
String ifaceName = implementedInterfaces[i];
int lastPoint=ifaceName.lastIndexOf('.');
if (lastPoint>=0) {
String ifaceNode = Toolkit.classNameToNodeName(ifaceName);
//"("+ifaceName.substring(0,lastPoint)+") "+ifaceName.substring(lastPoint+1);
ifaceEntry = new ClassEntry(ifaceName, ifaceNode); // FIXME! invalid
target node
interfaceEntries.put(ifaceName,ifaceEntry);
}
}
ifaceEntry.add(classEntry);
It looks like it's possibly intended to be inside an "else" statement,
or otherwise trapped (i.e. is it supposed to be something that is
"set" after the null check, or is it supposed to be an "alternative"
to the null check?). If you look at the context can see why
"ifaceEntry" won't necessarily be non-null, because the (lastPoint>=0)
test may not be true...
I'm not sure what the intended behaviour should be, which is why I
didn't fix in CVS. If it is, here's a patch that implements the
"else". If it's correct, let me know and I'll apply it:
cvs diff -u TreeNode.java
Index: TreeNode.java
===================================================================
RCS file:
/cvsroot/cp-tools/cp-tools/gnu/classpath/tools/doclets/texinfo/TreeNode.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 TreeNode.java
--- TreeNode.java 21 Oct 2001 14:06:46 -0000 1.1.1.1
+++ TreeNode.java 21 Feb 2002 08:59:35 -0000
@@ -181,7 +181,10 @@
interfaceEntries.put(ifaceName,ifaceEntry);
}
}
- ifaceEntry.add(classEntry);
+ else {
+ ifaceEntry.add(classEntry);
+ }
+
}
}
- [Cp-tools-discuss] bug + possible fix (patch) in texidoclet: TreeNode.java,
Alex Lancaster <=