From martinrb at google.com Mon Sep 9 11:49:56 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 9 Sep 2013 11:49:56 -0700 Subject: -Xdoclint + -Xprefer:source + incremental compilation == FAIL Message-ID: Hi doclint/javac folk, I reported this problem earlier, but that wasn't perhaps the best bug report. Here's another attempt that is independent of ant and hopefully provides a cleaner bug report with easy repro. (Inspired by the exciting release of jdk8-b106) I get an internal javac error, but only with the combination of -Xdoclint + -Xprefer:source + incremental compilation Not too many people will encounter this, but for those who do, it's a very serious bug, that seems like it should be easy to fix. Here's the repro: $ (set -eux; JAVAC=$HOME/jdk/jdk1.8.0-b106/bin/javac TMPDIR=/tmp/t9; my_javac() { $JAVAC -d classes -sourcepath src/main -XDignore.symbol.file=true -Xdoclint:all/protected -Xprefer:source "$@"; } ; rm -rf $TMPDIR && mkdir -p $TMPDIR && cd $TMPDIR && wget -q http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166.tar.gz && tar xf jsr166.tar.gz && cd jsr166 && mkdir -p classes && my_javac $(find src/main -name '*.java') && touch $(find src/main -name Queue.java) && my_javac $(find src/main -name Queue.java) ) +/bin/zsh:37> JAVAC=/usr/local/google/home/martinrb/jdk/jdk1.8.0-b106/bin/javac TMPDIR=/tmp/t9 +/bin/zsh:37> rm -rf /tmp/t9 +/bin/zsh:37> mkdir -p /tmp/t9 +/bin/zsh:37> cd /tmp/t9 +chpwd:1> [[ 13178 != 7283 ]] +chpwd:2> unfunction chpwd +/bin/zsh:37> wget -q http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166.tar.gz +/bin/zsh:37> tar xf jsr166.tar.gz +/bin/zsh:37> cd jsr166 +/bin/zsh:37> mkdir -p classes +/bin/zsh:37> find src/main -name '*.java' +/bin/zsh:37> my_javac src/main/java/util/NavigableSet.java [... snipped ... ] 15.23s user 0.32s system 439% cpu 3.540 total +/bin/zsh:37> find src/main -name Queue.java +/bin/zsh:37> touch src/main/java/util/Queue.java +/bin/zsh:37> find src/main -name Queue.java +/bin/zsh:37> my_javac src/main/java/util/Queue.java +my_javac:0> /usr/local/google/home/martinrb/jdk/jdk1.8.0-b106/bin/javac -d classes -sourcepath src/main '-XDignore.symbol.file=true' -Xdoclint:all/protected -Xprefer:source src/main/java/util/Queue.java Exception in thread "main" java.lang.RuntimeException: java.util.NoSuchElementException at com.sun.tools.javac.main.Main.compile(Main.java:559) at com.sun.tools.javac.main.Main.compile(Main.java:381) at com.sun.tools.javac.main.Main.compile(Main.java:370) at com.sun.tools.javac.main.Main.compile(Main.java:361) at com.sun.tools.javac.Main.compile(Main.java:64) at com.sun.tools.javac.Main.main(Main.java:50) Caused by: java.util.NoSuchElementException at java.util.LinkedList.removeFirst(LinkedList.java:270) at java.util.LinkedList.pop(LinkedList.java:801) at com.sun.tools.doclint.Checker.visitLink(Checker.java:649) at com.sun.tools.doclint.Checker.visitLink(Checker.java:91) at com.sun.tools.javac.tree.DCTree$DCLink.accept(DCTree.java:422) at com.sun.source.util.DocTreePathScanner.scan(DocTreePathScanner.java:65) at com.sun.source.util.DocTreeScanner.scanAndReduce(DocTreeScanner.java:81) at com.sun.source.util.DocTreeScanner.scan(DocTreeScanner.java:92) at com.sun.source.util.DocTreeScanner.scanAndReduce(DocTreeScanner.java:100) at com.sun.source.util.DocTreeScanner.visitDocComment(DocTreeScanner.java:140) at com.sun.tools.doclint.Checker.visitDocComment(Checker.java:213) at com.sun.tools.doclint.Checker.visitDocComment(Checker.java:91) at com.sun.tools.javac.tree.DCTree$DCDocComment.accept(DCTree.java:122) at com.sun.source.util.DocTreePathScanner.scan(DocTreePathScanner.java:47) at com.sun.tools.doclint.Checker.scan(Checker.java:175) at com.sun.tools.doclint.DocLint$2.visitDecl(DocLint.java:274) at com.sun.tools.doclint.DocLint$DeclScanner.visitClass(DocLint.java:338) at com.sun.tools.doclint.DocLint$DeclScanner.visitClass(DocLint.java:325) at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:714) at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:68) at com.sun.source.util.TreeScanner.scan(TreeScanner.java:91) at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:99) at com.sun.source.util.TreeScanner.visitCompilationUnit(TreeScanner.java:120) at com.sun.tools.doclint.DocLint$DeclScanner.visitCompilationUnit(DocLint.java:333) at com.sun.tools.doclint.DocLint$DeclScanner.visitCompilationUnit(DocLint.java:325) at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:550) at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:68) at com.sun.tools.doclint.DocLint$3.finished(DocLint.java:287) at com.sun.tools.javac.api.ClientCodeWrapper$WrappedTaskListener.finished(ClientCodeWrapper.java:681) at com.sun.tools.javac.api.MultiTaskListener.finished(MultiTaskListener.java:111) at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:986) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856) at com.sun.tools.javac.main.Main.compile(Main.java:523) ... 5 more -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20130909/c7ee13f0/attachment.html From jonathan.gibbons at oracle.com Mon Sep 9 12:31:49 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 09 Sep 2013 12:31:49 -0700 Subject: -Xdoclint + -Xprefer:source + incremental compilation == FAIL In-Reply-To: References: Message-ID: <522E2225.5030503@oracle.com> Martin, Noted. -- Jon On 09/09/2013 11:49 AM, Martin Buchholz wrote: > Hi doclint/javac folk, > > I reported this problem earlier, but that wasn't perhaps the best bug > report. Here's another attempt that is independent of ant and > hopefully provides a cleaner bug report with easy repro. (Inspired by > the exciting release of jdk8-b106) > > I get an internal javac error, but only with the combination of > -Xdoclint + -Xprefer:source + incremental compilation > > Not too many people will encounter this, but for those who do, it's a > very serious bug, that seems like it should be easy to fix. > > Here's the repro: > > $ (set -eux; JAVAC=$HOME/jdk/jdk1.8.0-b106/bin/javac TMPDIR=/tmp/t9; > my_javac() { $JAVAC -d classes -sourcepath src/main > -XDignore.symbol.file=true -Xdoclint:all/protected -Xprefer:source > "$@"; } ; rm -rf $TMPDIR && mkdir -p $TMPDIR && cd $TMPDIR && wget -q > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166.tar.gz && tar xf > jsr166.tar.gz && cd jsr166 && mkdir -p classes && my_javac $(find > src/main -name '*.java') && touch $(find src/main -name Queue.java) && > my_javac $(find src/main -name Queue.java) ) > +/bin/zsh:37> > JAVAC=/usr/local/google/home/martinrb/jdk/jdk1.8.0-b106/bin/javac > TMPDIR=/tmp/t9 > +/bin/zsh:37> rm -rf /tmp/t9 > +/bin/zsh:37> mkdir -p /tmp/t9 > +/bin/zsh:37> cd /tmp/t9 > +chpwd:1> [[ 13178 != 7283 ]] > +chpwd:2> unfunction chpwd > +/bin/zsh:37> wget -q > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166.tar.gz > +/bin/zsh:37> tar xf jsr166.tar.gz > +/bin/zsh:37> cd jsr166 > +/bin/zsh:37> mkdir -p classes > +/bin/zsh:37> find src/main -name '*.java' > +/bin/zsh:37> my_javac src/main/java/util/NavigableSet.java [... > snipped ... ] > 15.23s user 0.32s system 439% cpu 3.540 total > +/bin/zsh:37> find src/main -name Queue.java > +/bin/zsh:37> touch src/main/java/util/Queue.java > +/bin/zsh:37> find src/main -name Queue.java > +/bin/zsh:37> my_javac src/main/java/util/Queue.java > +my_javac:0> > /usr/local/google/home/martinrb/jdk/jdk1.8.0-b106/bin/javac -d classes > -sourcepath src/main '-XDignore.symbol.file=true' > -Xdoclint:all/protected -Xprefer:source src/main/java/util/Queue.java > Exception in thread "main" java.lang.RuntimeException: > java.util.NoSuchElementException > at com.sun.tools.javac.main.Main.compile(Main.java:559) > at com.sun.tools.javac.main.Main.compile(Main.java:381) > at com.sun.tools.javac.main.Main.compile(Main.java:370) > at com.sun.tools.javac.main.Main.compile(Main.java:361) > at com.sun.tools.javac.Main.compile(Main.java:64) > at com.sun.tools.javac.Main.main(Main.java:50) > Caused by: java.util.NoSuchElementException > at java.util.LinkedList.removeFirst(LinkedList.java:270) > at java.util.LinkedList.pop(LinkedList.java:801) > at com.sun.tools.doclint.Checker.visitLink(Checker.java:649) > at com.sun.tools.doclint.Checker.visitLink(Checker.java:91) > at com.sun.tools.javac.tree.DCTree$DCLink.accept(DCTree.java:422) > at com.sun.source.util.DocTreePathScanner.scan(DocTreePathScanner.java:65) > at > com.sun.source.util.DocTreeScanner.scanAndReduce(DocTreeScanner.java:81) > at com.sun.source.util.DocTreeScanner.scan(DocTreeScanner.java:92) > at > com.sun.source.util.DocTreeScanner.scanAndReduce(DocTreeScanner.java:100) > at > com.sun.source.util.DocTreeScanner.visitDocComment(DocTreeScanner.java:140) > at com.sun.tools.doclint.Checker.visitDocComment(Checker.java:213) > at com.sun.tools.doclint.Checker.visitDocComment(Checker.java:91) > at com.sun.tools.javac.tree.DCTree$DCDocComment.accept(DCTree.java:122) > at com.sun.source.util.DocTreePathScanner.scan(DocTreePathScanner.java:47) > at com.sun.tools.doclint.Checker.scan(Checker.java:175) > at com.sun.tools.doclint.DocLint$2.visitDecl(DocLint.java:274) > at com.sun.tools.doclint.DocLint$DeclScanner.visitClass(DocLint.java:338) > at com.sun.tools.doclint.DocLint$DeclScanner.visitClass(DocLint.java:325) > at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:714) > at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:68) > at com.sun.source.util.TreeScanner.scan(TreeScanner.java:91) > at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:99) > at > com.sun.source.util.TreeScanner.visitCompilationUnit(TreeScanner.java:120) > at > com.sun.tools.doclint.DocLint$DeclScanner.visitCompilationUnit(DocLint.java:333) > at > com.sun.tools.doclint.DocLint$DeclScanner.visitCompilationUnit(DocLint.java:325) > at > com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:550) > at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:68) > at com.sun.tools.doclint.DocLint$3.finished(DocLint.java:287) > at > com.sun.tools.javac.api.ClientCodeWrapper$WrappedTaskListener.finished(ClientCodeWrapper.java:681) > at > com.sun.tools.javac.api.MultiTaskListener.finished(MultiTaskListener.java:111) > at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:986) > at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856) > at com.sun.tools.javac.main.Main.compile(Main.java:523) > ... 5 more -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20130909/1e85d0fd/attachment.html From jonathan.gibbons at oracle.com Tue Sep 10 09:58:10 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 10 Sep 2013 09:58:10 -0700 Subject: -Xdoclint + -Xprefer:source + incremental compilation == FAIL In-Reply-To: References: Message-ID: <522F4FA2.90802@oracle.com> This is now being tracked as 8024538. Normally, this should show up soon on bugs.sun.com, but the sync is "a bit sluggish" right now. -- Jon On 09/09/2013 11:49 AM, Martin Buchholz wrote: > Hi doclint/javac folk, > > I reported this problem earlier, but that wasn't perhaps the best bug > report. Here's another attempt that is independent of ant and > hopefully provides a cleaner bug report with easy repro. (Inspired by > the exciting release of jdk8-b106) > > I get an internal javac error, but only with the combination of > -Xdoclint + -Xprefer:source + incremental compilation > > Not too many people will encounter this, but for those who do, it's a > very serious bug, that seems like it should be easy to fix. > > Here's the repro: > > $ (set -eux; JAVAC=$HOME/jdk/jdk1.8.0-b106/bin/javac TMPDIR=/tmp/t9; > my_javac() { $JAVAC -d classes -sourcepath src/main > -XDignore.symbol.file=true -Xdoclint:all/protected -Xprefer:source > "$@"; } ; rm -rf $TMPDIR && mkdir -p $TMPDIR && cd $TMPDIR && wget -q > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166.tar.gz && tar xf > jsr166.tar.gz && cd jsr166 && mkdir -p classes && my_javac $(find > src/main -name '*.java') && touch $(find src/main -name Queue.java) && > my_javac $(find src/main -name Queue.java) ) > +/bin/zsh:37> > JAVAC=/usr/local/google/home/martinrb/jdk/jdk1.8.0-b106/bin/javac > TMPDIR=/tmp/t9 > +/bin/zsh:37> rm -rf /tmp/t9 > +/bin/zsh:37> mkdir -p /tmp/t9 > +/bin/zsh:37> cd /tmp/t9 > +chpwd:1> [[ 13178 != 7283 ]] > +chpwd:2> unfunction chpwd > +/bin/zsh:37> wget -q > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166.tar.gz > +/bin/zsh:37> tar xf jsr166.tar.gz > +/bin/zsh:37> cd jsr166 > +/bin/zsh:37> mkdir -p classes > +/bin/zsh:37> find src/main -name '*.java' > +/bin/zsh:37> my_javac src/main/java/util/NavigableSet.java [... > snipped ... ] > 15.23s user 0.32s system 439% cpu 3.540 total > +/bin/zsh:37> find src/main -name Queue.java > +/bin/zsh:37> touch src/main/java/util/Queue.java > +/bin/zsh:37> find src/main -name Queue.java > +/bin/zsh:37> my_javac src/main/java/util/Queue.java > +my_javac:0> > /usr/local/google/home/martinrb/jdk/jdk1.8.0-b106/bin/javac -d classes > -sourcepath src/main '-XDignore.symbol.file=true' > -Xdoclint:all/protected -Xprefer:source src/main/java/util/Queue.java > Exception in thread "main" java.lang.RuntimeException: > java.util.NoSuchElementException > at com.sun.tools.javac.main.Main.compile(Main.java:559) > at com.sun.tools.javac.main.Main.compile(Main.java:381) > at com.sun.tools.javac.main.Main.compile(Main.java:370) > at com.sun.tools.javac.main.Main.compile(Main.java:361) > at com.sun.tools.javac.Main.compile(Main.java:64) > at com.sun.tools.javac.Main.main(Main.java:50) > Caused by: java.util.NoSuchElementException > at java.util.LinkedList.removeFirst(LinkedList.java:270) > at java.util.LinkedList.pop(LinkedList.java:801) > at com.sun.tools.doclint.Checker.visitLink(Checker.java:649) > at com.sun.tools.doclint.Checker.visitLink(Checker.java:91) > at com.sun.tools.javac.tree.DCTree$DCLink.accept(DCTree.java:422) > at com.sun.source.util.DocTreePathScanner.scan(DocTreePathScanner.java:65) > at > com.sun.source.util.DocTreeScanner.scanAndReduce(DocTreeScanner.java:81) > at com.sun.source.util.DocTreeScanner.scan(DocTreeScanner.java:92) > at > com.sun.source.util.DocTreeScanner.scanAndReduce(DocTreeScanner.java:100) > at > com.sun.source.util.DocTreeScanner.visitDocComment(DocTreeScanner.java:140) > at com.sun.tools.doclint.Checker.visitDocComment(Checker.java:213) > at com.sun.tools.doclint.Checker.visitDocComment(Checker.java:91) > at com.sun.tools.javac.tree.DCTree$DCDocComment.accept(DCTree.java:122) > at com.sun.source.util.DocTreePathScanner.scan(DocTreePathScanner.java:47) > at com.sun.tools.doclint.Checker.scan(Checker.java:175) > at com.sun.tools.doclint.DocLint$2.visitDecl(DocLint.java:274) > at com.sun.tools.doclint.DocLint$DeclScanner.visitClass(DocLint.java:338) > at com.sun.tools.doclint.DocLint$DeclScanner.visitClass(DocLint.java:325) > at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:714) > at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:68) > at com.sun.source.util.TreeScanner.scan(TreeScanner.java:91) > at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:99) > at > com.sun.source.util.TreeScanner.visitCompilationUnit(TreeScanner.java:120) > at > com.sun.tools.doclint.DocLint$DeclScanner.visitCompilationUnit(DocLint.java:333) > at > com.sun.tools.doclint.DocLint$DeclScanner.visitCompilationUnit(DocLint.java:325) > at > com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:550) > at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:68) > at com.sun.tools.doclint.DocLint$3.finished(DocLint.java:287) > at > com.sun.tools.javac.api.ClientCodeWrapper$WrappedTaskListener.finished(ClientCodeWrapper.java:681) > at > com.sun.tools.javac.api.MultiTaskListener.finished(MultiTaskListener.java:111) > at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:986) > at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856) > at com.sun.tools.javac.main.Main.compile(Main.java:523) > ... 5 more -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20130910/ede18f2a/attachment-0001.html From jonathan.gibbons at oracle.com Tue Sep 10 11:20:50 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 10 Sep 2013 11:20:50 -0700 Subject: -Xdoclint + -Xprefer:source + incremental compilation == FAIL In-Reply-To: <522F4FA2.90802@oracle.com> References: <522F4FA2.90802@oracle.com> Message-ID: <522F6302.1010402@oracle.com> Martin, Thanks for the clever/thorough test case/demo. -- Jon On 09/10/2013 09:58 AM, Jonathan Gibbons wrote: > This is now being tracked as 8024538. > > Normally, this should show up soon on bugs.sun.com, but the sync is "a > bit sluggish" right now. > > -- Jon > > On 09/09/2013 11:49 AM, Martin Buchholz wrote: >> Hi doclint/javac folk, >> >> I reported this problem earlier, but that wasn't perhaps the best bug >> report. Here's another attempt that is independent of ant and >> hopefully provides a cleaner bug report with easy repro. (Inspired >> by the exciting release of jdk8-b106) >> >> I get an internal javac error, but only with the combination of >> -Xdoclint + -Xprefer:source + incremental compilation >> >> Not too many people will encounter this, but for those who do, it's a >> very serious bug, that seems like it should be easy to fix. >> >> Here's the repro: >> >> $ (set -eux; JAVAC=$HOME/jdk/jdk1.8.0-b106/bin/javac TMPDIR=/tmp/t9; >> my_javac() { $JAVAC -d classes -sourcepath src/main >> -XDignore.symbol.file=true -Xdoclint:all/protected -Xprefer:source >> "$@"; } ; rm -rf $TMPDIR && mkdir -p $TMPDIR && cd $TMPDIR && wget -q >> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166.tar.gz && tar xf >> jsr166.tar.gz && cd jsr166 && mkdir -p classes && my_javac $(find >> src/main -name '*.java') && touch $(find src/main -name Queue.java) >> && my_javac $(find src/main -name Queue.java) ) >> +/bin/zsh:37> >> JAVAC=/usr/local/google/home/martinrb/jdk/jdk1.8.0-b106/bin/javac >> TMPDIR=/tmp/t9 >> +/bin/zsh:37> rm -rf /tmp/t9 >> +/bin/zsh:37> mkdir -p /tmp/t9 >> +/bin/zsh:37> cd /tmp/t9 >> +chpwd:1> [[ 13178 != 7283 ]] >> +chpwd:2> unfunction chpwd >> +/bin/zsh:37> wget -q >> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166.tar.gz >> +/bin/zsh:37> tar xf jsr166.tar.gz >> +/bin/zsh:37> cd jsr166 >> +/bin/zsh:37> mkdir -p classes >> +/bin/zsh:37> find src/main -name '*.java' >> +/bin/zsh:37> my_javac src/main/java/util/NavigableSet.java [... >> snipped ... ] >> 15.23s user 0.32s system 439% cpu 3.540 total >> +/bin/zsh:37> find src/main -name Queue.java >> +/bin/zsh:37> touch src/main/java/util/Queue.java >> +/bin/zsh:37> find src/main -name Queue.java >> +/bin/zsh:37> my_javac src/main/java/util/Queue.java >> +my_javac:0> >> /usr/local/google/home/martinrb/jdk/jdk1.8.0-b106/bin/javac -d >> classes -sourcepath src/main '-XDignore.symbol.file=true' >> -Xdoclint:all/protected -Xprefer:source src/main/java/util/Queue.java >> Exception in thread "main" java.lang.RuntimeException: >> java.util.NoSuchElementException >> at com.sun.tools.javac.main.Main.compile(Main.java:559) >> at com.sun.tools.javac.main.Main.compile(Main.java:381) >> at com.sun.tools.javac.main.Main.compile(Main.java:370) >> at com.sun.tools.javac.main.Main.compile(Main.java:361) >> at com.sun.tools.javac.Main.compile(Main.java:64) >> at com.sun.tools.javac.Main.main(Main.java:50) >> Caused by: java.util.NoSuchElementException >> at java.util.LinkedList.removeFirst(LinkedList.java:270) >> at java.util.LinkedList.pop(LinkedList.java:801) >> at com.sun.tools.doclint.Checker.visitLink(Checker.java:649) >> at com.sun.tools.doclint.Checker.visitLink(Checker.java:91) >> at com.sun.tools.javac.tree.DCTree$DCLink.accept(DCTree.java:422) >> at >> com.sun.source.util.DocTreePathScanner.scan(DocTreePathScanner.java:65) >> at >> com.sun.source.util.DocTreeScanner.scanAndReduce(DocTreeScanner.java:81) >> at com.sun.source.util.DocTreeScanner.scan(DocTreeScanner.java:92) >> at >> com.sun.source.util.DocTreeScanner.scanAndReduce(DocTreeScanner.java:100) >> at >> com.sun.source.util.DocTreeScanner.visitDocComment(DocTreeScanner.java:140) >> at com.sun.tools.doclint.Checker.visitDocComment(Checker.java:213) >> at com.sun.tools.doclint.Checker.visitDocComment(Checker.java:91) >> at com.sun.tools.javac.tree.DCTree$DCDocComment.accept(DCTree.java:122) >> at >> com.sun.source.util.DocTreePathScanner.scan(DocTreePathScanner.java:47) >> at com.sun.tools.doclint.Checker.scan(Checker.java:175) >> at com.sun.tools.doclint.DocLint$2.visitDecl(DocLint.java:274) >> at com.sun.tools.doclint.DocLint$DeclScanner.visitClass(DocLint.java:338) >> at com.sun.tools.doclint.DocLint$DeclScanner.visitClass(DocLint.java:325) >> at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:714) >> at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:68) >> at com.sun.source.util.TreeScanner.scan(TreeScanner.java:91) >> at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:99) >> at >> com.sun.source.util.TreeScanner.visitCompilationUnit(TreeScanner.java:120) >> at >> com.sun.tools.doclint.DocLint$DeclScanner.visitCompilationUnit(DocLint.java:333) >> at >> com.sun.tools.doclint.DocLint$DeclScanner.visitCompilationUnit(DocLint.java:325) >> at >> com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:550) >> at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:68) >> at com.sun.tools.doclint.DocLint$3.finished(DocLint.java:287) >> at >> com.sun.tools.javac.api.ClientCodeWrapper$WrappedTaskListener.finished(ClientCodeWrapper.java:681) >> at >> com.sun.tools.javac.api.MultiTaskListener.finished(MultiTaskListener.java:111) >> at >> com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:986) >> at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856) >> at com.sun.tools.javac.main.Main.compile(Main.java:523) >> ... 5 more > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20130910/79beb138/attachment.html From msimacek at redhat.com Thu Sep 19 10:00:24 2013 From: msimacek at redhat.com (Michael Simacek) Date: Thu, 19 Sep 2013 13:00:24 -0400 (EDT) Subject: VisibleMemberMap.java possible performance improvements In-Reply-To: <113072447.8411655.1379606556054.JavaMail.root@redhat.com> Message-ID: <1014392850.8435721.1379610024211.JavaMail.root@redhat.com> Hi, I thought about improving performance of the default doclet implementation a bit. According to profiler results, most of the CPU time is spent in constructing the member map in VisibleMemberMap.java. So I've rewritten part of the VisbleMemberMap and reduced the javadoc run time to 60-70% of original run time (on large inputs). Is there any chance of this patch (attached) being accepted into OpenJDK? I've never made any contribution to OpenJDK before, so I would like to ask for code review and guidance through the contribution process. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: VisibleMemberMap.patch Type: text/x-patch Size: 14156 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20130919/f890ea9c/VisibleMemberMap.patch From jonathan.gibbons at oracle.com Thu Sep 19 10:46:55 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 19 Sep 2013 10:46:55 -0700 Subject: VisibleMemberMap.java possible performance improvements In-Reply-To: <1014392850.8435721.1379610024211.JavaMail.root@redhat.com> References: <1014392850.8435721.1379610024211.JavaMail.root@redhat.com> Message-ID: <523B388F.8070302@oracle.com> On 09/19/2013 10:00 AM, Michael Simacek wrote: > Hi, > > I thought about improving performance of the default doclet implementation a bit. > According to profiler results, most of the CPU time is spent in constructing the member map in VisibleMemberMap.java. > So I've rewritten part of the VisbleMemberMap and reduced the javadoc run time to 60-70% of original run time (on large inputs). > > Is there any chance of this patch (attached) being accepted into OpenJDK? > I've never made any contribution to OpenJDK before, so I would like to ask for code review and guidance through the contribution process. > > Michael > Michael, Just from the description, this sounds interesting. There are two criteria for a change like this: -- the obvious one -- do all the javadoc regression tests pass. These are the tests langtools/test/com/sun/javadoc langtools/test/tools/javadoc -- does the change affect the generated docs. Unfortunately, you cannot trivially use comparison tools (like diff) to compare the output, because of various date stamps within the generated docs. Changing the makefiles to disable the date stamps is not a solution either, because of timestamps in other artifacts generated during the build (corba files.) My personal solution is to use a script (attached) to scrub time and date stamps from generated docs. Run this script on a directory such as the generated docs directory and it will remove any timestamp info using "sed --in-place". Once you have done that you can use tools like diff and meld to compare the generated docs before and after applying your patch. -- Jon -------------- next part -------------- #!/bin/sh # Remove timestamps from html files generated by javadoc. # This includes timestamps generated by javadoc itself, # and timestamps propogated from the javadoc comments. for file in $(find $1 -name \*.html | xargs -n 1 grep --files-with-matches "Generated by javadoc" ) ; do sed --in-place \ -e 's/\(-- Generated by javadoc \).*\( --\)/\1(removed)\2/' \ -e 's/\(\)/\1(removed)\2/' \ -e 's/\(Monday\|Tuesday\|Wednesday\|Thursday\|Friday\|Saturday\|Sunday\), [A-Z][a-z]* [0-9][0-9]*, [12][0-9]* [0-9][0-9:]* \(AM\|PM\) PDT/(removed)/' \ $file done From jonathan.gibbons at oracle.com Thu Sep 19 10:54:02 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 19 Sep 2013 10:54:02 -0700 Subject: VisibleMemberMap.java possible performance improvements In-Reply-To: <1014392850.8435721.1379610024211.JavaMail.root@redhat.com> References: <1014392850.8435721.1379610024211.JavaMail.root@redhat.com> Message-ID: <523B3A3A.1040509@oracle.com> On 09/19/2013 10:00 AM, Michael Simacek wrote: > Is there any chance of this patch (attached) being accepted into OpenJDK? > I've never made any contribution to OpenJDK before, so I would like to ask for code review and guidance through the contribution process. > > Michael For reference, the general process of making a contributions is described here: http://openjdk.java.net/contribute/ ... but you've come to the right place/mailing list to ask questions. -- Jon From jonathan.gibbons at oracle.com Thu Sep 19 11:02:00 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 19 Sep 2013 11:02:00 -0700 Subject: VisibleMemberMap.java possible performance improvements In-Reply-To: <1014392850.8435721.1379610024211.JavaMail.root@redhat.com> References: <1014392850.8435721.1379610024211.JavaMail.root@redhat.com> Message-ID: <523B3C18.1030807@oracle.com> On 09/19/2013 10:00 AM, Michael Simacek wrote: > Hi, > > I thought about improving performance of the default doclet implementation a bit. > According to profiler results, most of the CPU time is spent in constructing the member map in VisibleMemberMap.java. > So I've rewritten part of the VisbleMemberMap and reduced the javadoc run time to 60-70% of original run time (on large inputs). > > Is there any chance of this patch (attached) being accepted into OpenJDK? > I've never made any contribution to OpenJDK before, so I would like to ask for code review and guidance through the contribution process. > > Michael > I've filed JDK-8025091 to track this work -- and now that bugs.openjdk.java.net is publicly accessible, you should be able to view it yourself. The bug should be visible here: https://bugs.openjdk.java.net/browse/JDK-8025091 -- Jon From jonathan.gibbons at oracle.com Thu Sep 19 12:00:41 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 19 Sep 2013 12:00:41 -0700 Subject: VisibleMemberMap.java possible performance improvements In-Reply-To: <523B3C18.1030807@oracle.com> References: <1014392850.8435721.1379610024211.JavaMail.root@redhat.com> <523B3C18.1030807@oracle.com> Message-ID: <523B49D9.80802@oracle.com> On 09/19/2013 11:02 AM, Jonathan Gibbons wrote: > On 09/19/2013 10:00 AM, Michael Simacek wrote: >> Hi, >> >> I thought about improving performance of the default doclet >> implementation a bit. >> According to profiler results, most of the CPU time is spent in >> constructing the member map in VisibleMemberMap.java. >> So I've rewritten part of the VisbleMemberMap and reduced the javadoc >> run time to 60-70% of original run time (on large inputs). >> >> Is there any chance of this patch (attached) being accepted into >> OpenJDK? >> I've never made any contribution to OpenJDK before, so I would like >> to ask for code review and guidance through the contribution process. >> >> Michael >> > > I've filed JDK-8025091 to track this work -- and now that > bugs.openjdk.java.net is publicly accessible, you should be able to > view it yourself. > > The bug should be visible here: > https://bugs.openjdk.java.net/browse/JDK-8025091 > > -- Jon > > Michael's patch is now visible as a webrev at http://cr.openjdk.java.net/~jjg/8025091/webrev.00/ -- Jon From jonathan.gibbons at oracle.com Thu Sep 19 12:10:07 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 19 Sep 2013 12:10:07 -0700 Subject: VisibleMemberMap.java possible performance improvements In-Reply-To: <523B388F.8070302@oracle.com> References: <1014392850.8435721.1379610024211.JavaMail.root@redhat.com> <523B388F.8070302@oracle.com> Message-ID: <523B4C0F.8060506@oracle.com> On 09/19/2013 10:46 AM, Jonathan Gibbons wrote: > > There are two criteria for a change like this: > > -- the obvious one -- do all the javadoc regression tests pass. These > are the tests > langtools/test/com/sun/javadoc > langtools/test/tools/javadoc Two regression tests fail when the patch is applied to the latest jdk8/tl/langtools repository: com/sun/javadoc/testAnnotationTypes/TestAnnotationTypes.java com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java There have been recent changesets in this area, so maybe the code for your patch just needs updating. -- Jon From jonathan.gibbons at oracle.com Thu Sep 19 13:59:41 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 19 Sep 2013 13:59:41 -0700 Subject: VisibleMemberMap.java possible performance improvements In-Reply-To: <523B388F.8070302@oracle.com> References: <1014392850.8435721.1379610024211.JavaMail.root@redhat.com> <523B388F.8070302@oracle.com> Message-ID: <523B65BD.1010808@oracle.com> On 09/19/2013 10:46 AM, Jonathan Gibbons wrote: > > > -- does the change affect the generated docs. ... and the answer is "yes". :-) The order of some parts of the generated docs differs before/after the patch. This is an issue which needs to be fixed. At first, I thought it was due to the use of HashMap (which is a common source of inconsistent ordering) but I see the old code uses HashMap too -- and I've not seen ordering problems before. Having looked at a few more files, I think that the problem is just in lists of inherited items, and specifically the order in which you create the lists in the new code may be the reverse of the order in which they were created before. -- Jon From msimacek at redhat.com Mon Sep 23 05:36:53 2013 From: msimacek at redhat.com (Michael Simacek) Date: Mon, 23 Sep 2013 08:36:53 -0400 (EDT) Subject: VisibleMemberMap.java possible performance improvements In-Reply-To: <523B65BD.1010808@oracle.com> References: <1014392850.8435721.1379610024211.JavaMail.root@redhat.com> <523B388F.8070302@oracle.com> <523B65BD.1010808@oracle.com> Message-ID: <1817853488.309979.1379939813024.JavaMail.root@redhat.com> Thank you for your help, Jon. I've rewritten it a bit (also had to change the Util.executableMembersEqual method to fix some issues), so now all the tests should pass and I have fixed some other bugs. Now the order of classes is the same and order of interfaces is mostly the same. I tried to get as close to the original as possible, but although it seems I'm traversing the inheritance tree the same way as original implementation, I'm unable to retain the exact original order. But in most cases it is the same. What are the reasons for the order to stay the same? I tried to do the diff on java.lang and java.util and there are some differences, but I'm not sure which version is correct: 1. In java.lang.StringBuilder there is a section 'Methods inherited from interface CharSequence'. In the original version it contains charAt, chars, codePoints, length, subSequence and in mine contains just chars, codePoints. But the methods charAt, length and subSequence are overriden by the StringBuilder class, so I don't think they should be there. What do you think? The same thing appears in other classes, for example ArrayList. 2. AbstractQueue (and other Collections) - similar case as the above, but the methods are overriden in one of the parent classes. 3. In HashMap (and any other implementations of Map) there is no MapEntry inner interface in the original version, whereas in mine there is. It is public inner interface and it is not hidden by anything, so I cannot see a reason why it shouldn't be there. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: VisibleMemberMap.patch Type: text/x-patch Size: 19333 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20130923/e84e4052/VisibleMemberMap.patch From jonathan.gibbons at oracle.com Wed Sep 25 16:02:01 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 Sep 2013 16:02:01 -0700 Subject: VisibleMemberMap.java possible performance improvements In-Reply-To: <1817853488.309979.1379939813024.JavaMail.root@redhat.com> References: <1014392850.8435721.1379610024211.JavaMail.root@redhat.com> <523B388F.8070302@oracle.com> <523B65BD.1010808@oracle.com> <1817853488.309979.1379939813024.JavaMail.root@redhat.com> Message-ID: <52436B69.7070009@oracle.com> On 09/23/2013 05:36 AM, Michael Simacek wrote: > Thank you for your help, Jon. > > I've rewritten it a bit (also had to change the Util.executableMembersEqual method to fix some issues), > so now all the tests should pass and I have fixed some other bugs. > Now the order of classes is the same and order of interfaces is mostly the same. > I tried to get as close to the original as possible, but although it seems I'm > traversing the inheritance tree the same way as original implementation, I'm unable to retain > the exact original order. But in most cases it is the same. What are the reasons for the > order to stay the same? > > I tried to do the diff on java.lang and java.util and there are some differences, but I'm not > sure which version is correct: > 1. In java.lang.StringBuilder there is a section 'Methods inherited from interface CharSequence'. > In the original version it contains charAt, chars, codePoints, length, subSequence and in mine > contains just chars, codePoints. But the methods charAt, length and subSequence are overriden > by the StringBuilder class, so I don't think they should be there. What do you think? > The same thing appears in other classes, for example ArrayList. > > 2. AbstractQueue (and other Collections) - similar case as the above, but the methods are overriden in > one of the parent classes. > > 3. In HashMap (and any other implementations of Map) there is no MapEntry inner interface in the > original version, whereas in mine there is. It is public inner interface and it is not hidden > by anything, so I cannot see a reason why it shouldn't be there. > > Michael > > > Michael, This is not so good. What started off as a performance rewrite of one particular class has now expanded beyond that, as you have "fixed some other bugs". Even worse, the output is only "mostly the same" as before. Here are the general guidelines ... If you are refactoring code, such as for a performance improvement, you don't have to write any new tests, but the presumption is you are not changing the functional behavior, meaning that all existing tests should continue to pass, and the externally visible functionality should be unchanged, meaning in this case that the generated output should be the same (after allowing for differences like timestamps in the output.) If you are fixing bugs, they need to identified separately, and unless they are very closely related, each with its own issue in bugs.openjdk.java.net, each one fixed and reviewed separately, and each with its own test(s), such as you might find in langtools/test/com/sun/javadoc. JDK 8 is nearing completion. The Developer Preview has been announced [1]. This means we have to start being more conservative in any changes targeted at JDK 8. There is a small window of opportunity remaining for a performance-refactoring of VisibleMemberMap, but to be conservative, we cannot consider a refactoring that also changes the generated output. If you can cite specific bugs in the currently generated output, then we can consider accepting appropriate bug fixes for those issues. -- Jon [1] http://mreinhold.org/blog/jdk8-preview From jonathan.gibbons at oracle.com Wed Sep 25 16:20:11 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 Sep 2013 16:20:11 -0700 Subject: VisibleMemberMap.java possible performance improvements In-Reply-To: <1817853488.309979.1379939813024.JavaMail.root@redhat.com> References: <1014392850.8435721.1379610024211.JavaMail.root@redhat.com> <523B388F.8070302@oracle.com> <523B65BD.1010808@oracle.com> <1817853488.309979.1379939813024.JavaMail.root@redhat.com> Message-ID: <52436FAB.6080404@oracle.com> On 09/23/2013 05:36 AM, Michael Simacek wrote: > Thank you for your help, Jon. > > I've rewritten it a bit (also had to change the Util.executableMembersEqual method to fix some issues), > so now all the tests should pass and I have fixed some other bugs. > Now the order of classes is the same and order of interfaces is mostly the same. > I tried to get as close to the original as possible, but although it seems I'm > traversing the inheritance tree the same way as original implementation, I'm unable to retain > the exact original order. But in most cases it is the same. What are the reasons for the > order to stay the same? > > I tried to do the diff on java.lang and java.util and there are some differences, but I'm not > sure which version is correct: > 1. In java.lang.StringBuilder there is a section 'Methods inherited from interface CharSequence'. > In the original version it contains charAt, chars, codePoints, length, subSequence and in mine > contains just chars, codePoints. But the methods charAt, length and subSequence are overriden > by the StringBuilder class, so I don't think they should be there. What do you think? > The same thing appears in other classes, for example ArrayList. > > 2. AbstractQueue (and other Collections) - similar case as the above, but the methods are overriden in > one of the parent classes. > > 3. In HashMap (and any other implementations of Map) there is no MapEntry inner interface in the > original version, whereas in mine there is. It is public inner interface and it is not hidden > by anything, so I cannot see a reason why it shouldn't be there. > > Michael > > > For anyone else wishing to see Michael's patch as a webre, it is available at http://cr.openjdk.java.net/~jjg/8025091/webrev.01 -- Jon From martinrb at google.com Thu Sep 26 17:16:50 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 26 Sep 2013 17:16:50 -0700 Subject: RFR 8025173 : HashMap.put() replacing an existing key can trigger a resize() In-Reply-To: <52447430.9070300@oracle.com> References: <5243616F.1000006@oracle.com> <52447430.9070300@oracle.com> Message-ID: Yes, I see your problem. It's one we have in jsr166 development as well. We would like to use javadoc style, and have the javadoc tool warn us of "real bugs" in our javadoc (even private methods) BUT we don't want javadoc to enforce the same high standards for public methods, e.g. don't require all of the @param for type parameters. I think javadoc's current increased level of warning will have the unintended consequence of causing users to revert to /* comments. I would disable the more controversial ones by default. On Thu, Sep 26, 2013 at 10:51 AM, Brent Christian < brent.christian at oracle.com> wrote: > On 9/25/13 4:03 PM, Martin Buchholz wrote: > >> Looks good. >> I would only suggest the stylistic improvement of using proper /** >> javadoc comments even for private test methods instead of /* >> > > The comments were meant as internal documentation and not "real" javadoc. > After dabbling with some doclint cleanup a while ago, I'm inclined now to > only use /** if what I'm writing will be doclint-clean. testItr(), for > instance, would (at least) need @param tags and that's more than I thought > was needed for this test code. > > So that was the thinking there. > > Thanks, > -Brent > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20130926/a2ffa749/attachment.html From jonathan.gibbons at oracle.com Thu Sep 26 17:45:21 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 26 Sep 2013 17:45:21 -0700 Subject: RFR 8025173 : HashMap.put() replacing an existing key can trigger a resize() In-Reply-To: References: <5243616F.1000006@oracle.com> <52447430.9070300@oracle.com> Message-ID: <5244D521.1080809@oracle.com> The new diagnostics are generated by the new doclint feature which is available from the javac and javadoc command lines. When invoked from javadoc, it only checks the comments being used for the docs that you are generating. So, if you are generating docs for just your public and protected methods, doclint will not (or should not) warn about your package-private and private methods. The decision of which doc comments to check comes from the standard javadoc command line options used to select the elements to document, i.e. -private, -package, -protected, -public. When invoked from javac, you actually have somewhat more versatility. The -Xdoclint command line option for javac actually allows you to specify different access levels for different types of check, so you could check syntax errors for all comments but only check for missing comments on public and protected elements. With respect to your specific comments, I wonder if there is a typo in your message, because it doesn't quite make sense as written: > We would like to use javadoc style, and have the javadoc tool warn us > of "real bugs" in our javadoc (even private methods) BUT we don't want > javadoc to enforce the same high standards for public methods, e.g. > don't require all of the @param for type parameters. The word "public" in "the same high standards for public methods" makes more sense to me if you meant "private" here. Which did you really mean? -- Jon On 09/26/2013 05:16 PM, Martin Buchholz wrote: > Yes, I see your problem. It's one we have in jsr166 development as well. > > We would like to use javadoc style, and have the javadoc tool warn us > of "real bugs" in our javadoc (even private methods) BUT we don't want > javadoc to enforce the same high standards for public methods, e.g. > don't require all of the @param for type parameters. > > I think javadoc's current increased level of warning will have the > unintended consequence of causing users to revert to /* comments. > I would disable the more controversial ones by default. > > > On Thu, Sep 26, 2013 at 10:51 AM, Brent Christian > > wrote: > > On 9/25/13 4:03 PM, Martin Buchholz wrote: > > Looks good. > I would only suggest the stylistic improvement of using proper /** > javadoc comments even for private test methods instead of /* > > > The comments were meant as internal documentation and not "real" > javadoc. After dabbling with some doclint cleanup a while ago, > I'm inclined now to only use /** if what I'm writing will be > doclint-clean. testItr(), for instance, would (at least) need > @param tags and that's more than I thought was needed for this > test code. > > So that was the thinking there. > > Thanks, > -Brent > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20130926/3308327c/attachment.html From martinrb at google.com Thu Sep 26 18:00:24 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 26 Sep 2013 18:00:24 -0700 Subject: RFR 8025173 : HashMap.put() replacing an existing key can trigger a resize() In-Reply-To: <5244D521.1080809@oracle.com> References: <5243616F.1000006@oracle.com> <52447430.9070300@oracle.com> <5244D521.1080809@oracle.com> Message-ID: On Thu, Sep 26, 2013 at 5:45 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > The new diagnostics are generated by the new doclint feature which is > available from the javac and javadoc command lines. > > When invoked from javadoc, it only checks the comments being used for the > docs that you are generating. So, if you are generating docs for just your > public and protected methods, doclint will not (or should not) warn about > your package-private and private methods. The decision of which doc > comments to check comes from the standard javadoc command line options used > to select the elements to document, i.e. -private, -package, -protected, > -public. > > When invoked from javac, you actually have somewhat more versatility. The > -Xdoclint command line option for javac actually allows you to specify > different access levels for different types of check, so you could check > syntax errors for all comments but only check for missing comments on > public and protected elements. > > With respect to your specific comments, I wonder if there is a typo in > your message, because it doesn't quite make sense as written: > > > We would like to use javadoc style, and have the javadoc tool warn us of > "real bugs" in our javadoc (even private methods) BUT we don't want javadoc > to enforce the same high standards for public methods, e.g. don't require > all of the @param for type parameters. > > > The word "public" in "the same high standards for public methods" makes > more sense to me if you meant "private" here. Which did you really mean? > I really meant "BUT we don't want javadoc, when run against private methods, to enforce the same high standards as for public methods" E.g. for maintainers, adding @param or @returns (or @SuppressWarnings) to the method below is not an improvement. /** * Returns the trigger time of a delayed action. */ private long triggerTime(long delay, TimeUnit unit) { return triggerTime(unit.toNanos((delay < 0) ? 0 : delay)); } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20130926/8163a63c/attachment.html From jonathan.gibbons at oracle.com Thu Sep 26 18:07:18 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 26 Sep 2013 18:07:18 -0700 Subject: RFR 8025173 : HashMap.put() replacing an existing key can trigger a resize() In-Reply-To: References: <5243616F.1000006@oracle.com> <52447430.9070300@oracle.com> <5244D521.1080809@oracle.com> Message-ID: <5244DA46.5000507@oracle.com> On 09/26/2013 06:00 PM, Martin Buchholz wrote: > > > > On Thu, Sep 26, 2013 at 5:45 PM, Jonathan Gibbons > > wrote: > > The new diagnostics are generated by the new doclint feature which > is available from the javac and javadoc command lines. > > When invoked from javadoc, it only checks the comments being used > for the docs that you are generating. So, if you are generating > docs for just your public and protected methods, doclint will not > (or should not) warn about your package-private and private > methods. The decision of which doc comments to check comes from > the standard javadoc command line options used to select the > elements to document, i.e. -private, -package, -protected, -public. > > When invoked from javac, you actually have somewhat more > versatility. The -Xdoclint command line option for javac actually > allows you to specify different access levels for different types > of check, so you could check syntax errors for all comments but > only check for missing comments on public and protected elements. > > With respect to your specific comments, I wonder if there is a > typo in your message, because it doesn't quite make sense as written: > > >> We would like to use javadoc style, and have the javadoc tool >> warn us of "real bugs" in our javadoc (even private methods) BUT >> we don't want javadoc to enforce the same high standards for >> public methods, e.g. don't require all of the @param for type >> parameters. > > The word "public" in "the same high standards for public methods" > makes more sense to me if you meant "private" here. Which did you > really mean? > > > I really meant "BUT we don't want javadoc, when run against private > methods, to enforce the same high standards as for public methods" > > E.g. for maintainers, adding @param or @returns (or @SuppressWarnings) > to the method below is not an improvement. > > /** > * Returns the trigger time of a delayed action. > */ > private long triggerTime(long delay, TimeUnit unit) { > return triggerTime(unit.toNanos((delay < 0) ? 0 : delay)); > } > Martin, OK, yes, that is more what I was expecting you meant. We ran across exactly the same situation when applying doclint to our own code. If you invoke doclint from javac, you should have the flexibility you are looking for in the -Xdoclint option and its suboptions. You can set a high standard for public and protected methods, and a lower standard (or no standard) for private and package-private methods. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20130926/df650bd1/attachment-0001.html From msimacek at redhat.com Thu Sep 26 01:21:08 2013 From: msimacek at redhat.com (Michael Simacek) Date: Thu, 26 Sep 2013 08:21:08 -0000 Subject: VisibleMemberMap.java possible performance improvements In-Reply-To: <1333641510.1703035.1380183181498.JavaMail.root@redhat.com> Message-ID: <627847526.1704652.1380183667527.JavaMail.root@redhat.com> Ok, so are these three items I mentioned bugs in the original implementation? And I should report each of them separately and try to fix them in the original implementation, right? Or should I propose my patch (or part of it) as a fix for them (with tests ofc)? Michael Simacek