From jonathan.gibbons at oracle.com Fri Jun 17 02:28:34 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 16 Jun 2016 19:28:34 -0700 Subject: RFR: 8154399, 8159096, export packages containing standard javadoc doclet Message-ID: <57636052.7070700@oracle.com> Please review this simple fix for two related aspects of the same problem: Export the "standard doclet" used by javadoc, such that it is possible to derive alternative doclets, either by delegation or subtyping. In JDK 9, javadoc has a "new" standard doclet (JEP 221), but the old one remains for compatibility, for the time being. Both should be exported. Jigsaw folk: Please review the changes to jdk.javadoc module-info. Build folk: The javadoc documentation is extended to include the documentation for the package containing the new StandardDoclet. (The API for the old StandardDoclet was never published in this manner; it is only included in the javadoc tool guide, which remains unchanged, for now.) javadoc folk: The top level class for the new StandardDoclet is moved, without any functional change, from an internal package to the new exported package. JBS: https://bugs.openjdk.java.net/browse/JDK-8154399 https://bugs.openjdk.java.net/browse/JDK-8159096 Webrev: http://cr.openjdk.java.net/~jjg/8154399/webrev.00 -- Jon From Alan.Bateman at oracle.com Fri Jun 17 10:51:02 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jun 2016 11:51:02 +0100 Subject: RFR: 8154399, 8159096, export packages containing standard javadoc doclet In-Reply-To: <57636052.7070700@oracle.com> References: <57636052.7070700@oracle.com> Message-ID: <975e600b-35e8-6f5e-52ad-973e6ecb8280@oracle.com> On 17/06/2016 03:28, Jonathan Gibbons wrote: > Please review this simple fix for two related aspects of the same > problem: > > Export the "standard doclet" used by javadoc, such that it is possible > to derive alternative doclets, either by delegation or subtyping. > > In JDK 9, javadoc has a "new" standard doclet (JEP 221), but the old > one remains for compatibility, for the time being. Both should be > exported. > > > Jigsaw folk: > Please review the changes to jdk.javadoc module-info. > > Build folk: > The javadoc documentation is extended to include the documentation > for the package containing the new StandardDoclet. > (The API for the old StandardDoclet was never published in this > manner; it is only included in the javadoc tool guide, which remains > unchanged, for now.) > > javadoc folk: > The top level class for the new StandardDoclet is moved, without > any functional change, from an internal package to the new exported > package. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8154399 > https://bugs.openjdk.java.net/browse/JDK-8159096 > Webrev: http://cr.openjdk.java.net/~jjg/8154399/webrev.00 This looks okay to me, I just wonder if StandardDoclet should be final - do you remember want that to be extended? -Alan From mandy.chung at oracle.com Fri Jun 17 02:54:48 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 16 Jun 2016 19:54:48 -0700 Subject: RFR: 8154399, 8159096, export packages containing standard javadoc doclet In-Reply-To: <57636052.7070700@oracle.com> References: <57636052.7070700@oracle.com> Message-ID: <23F263ED-F0C1-4C30-BF8B-5CC0D95078FD@oracle.com> > On Jun 16, 2016, at 7:28 PM, Jonathan Gibbons wrote: > > Please review this simple fix for two related aspects of the same problem: > > Export the "standard doclet" used by javadoc, such that it is possible to derive alternative doclets, either by delegation or subtyping. > > In JDK 9, javadoc has a "new" standard doclet (JEP 221), but the old one remains for compatibility, for the time being. Both should be exported. > > > Jigsaw folk: > Please review the changes to jdk.javadoc module-info. > > Build folk: > The javadoc documentation is extended to include the documentation for the package containing the new StandardDoclet. > (The API for the old StandardDoclet was never published in this manner; it is only included in the javadoc tool guide, which remains unchanged, for now.) > > javadoc folk: > The top level class for the new StandardDoclet is moved, without any functional change, from an internal package to the new exported package. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8154399 > https://bugs.openjdk.java.net/browse/JDK-8159096 > Webrev: http://cr.openjdk.java.net/~jjg/8154399/webrev.00 Looks fine to me. I?m sure you have considered the name of the new package is only one-character difference than jdk.javadoc.doclet. Just wonder what the relationale is behind why the new StandardDoclet class is in a new package rather than in jdk.javadoc.doclet? Mandy From kumar.x.srinivasan at oracle.com Mon Jun 20 23:18:29 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 20 Jun 2016 16:18:29 -0700 Subject: RFR: 8159305: Enhance the javadoc tool to support module related options Message-ID: <576879C5.3020306@oracle.com> Hello, Please review the changes to fix: https://bugs.openjdk.java.net/browse/JDK-8159305 The webrev is here: http://cr.openjdk.java.net/~ksrini/8159305/webrev.00/ The spec-diff is here for reference: http://cr.openjdk.java.net/~ksrini/8159305/spec-diff/overview-summary.html Thanks Kumar From martinrb at google.com Mon Jun 20 23:37:27 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 20 Jun 2016 16:37:27 -0700 Subject: RFR: 8159305: Enhance the javadoc tool to support module related options In-Reply-To: <576879C5.3020306@oracle.com> References: <576879C5.3020306@oracle.com> Message-ID: Hi Kumar, Is this intended to address the jsr166 use case (source files belong to a module, but not the entire module is being processed, and not all module sources are in a single tree)? Currently, jsr166 CVS docs are still broken. "ant docs" fails with [javadoc] java.lang.AssertionError [javadoc] at com.sun.tools.javac.util.Assert.error(jdk.compiler at 9-ea /Assert.java:155) [javadoc] at com.sun.tools.javac.util.Assert.checkNull(jdk.compiler at 9-ea /Assert.java:54) [javadoc] at com.sun.tools.javac.code.Symtab.enterModule(jdk.compiler at 9-ea /Symtab.java:755) [javadoc] at com.sun.tools.javac.comp.Modules.enterModule(jdk.compiler at 9-ea /Modules.java:262) [javadoc] at com.sun.tools.javac.comp.Modules.enterModules(jdk.compiler at 9-ea /Modules.java:240) [javadoc] at com.sun.tools.javac.comp.Modules.enter(jdk.compiler at 9-ea /Modules.java:208) [javadoc] at com.sun.tools.javac.main.JavaCompiler.readSourceFile(jdk.compiler at 9-ea /JavaCompiler.java:816) [javadoc] at com.sun.tools.javac.main.JavaCompiler.readSourceFile(jdk.compiler at 9-ea /JavaCompiler.java:778) [javadoc] at com.sun.tools.javac.main.JavaCompiler.access$100(jdk.compiler at 9-ea /JavaCompiler.java:97) [javadoc] at com.sun.tools.javac.main.JavaCompiler$1.complete(jdk.compiler at 9-ea /JavaCompiler.java:339) [javadoc] at com.sun.tools.javac.code.ClassFinder.fillIn(jdk.compiler at 9-ea /ClassFinder.java:362) [javadoc] at com.sun.tools.javac.code.ModuleFinder.lambda$findSingleModule$0(jdk.compiler at 9-ea /ModuleFinder.java:206) [javadoc] at com.sun.tools.javac.code.Symbol.complete(jdk.compiler at 9-ea /Symbol.java:602) [javadoc] at com.sun.tools.javac.comp.Modules.setCompilationUnitModules(jdk.compiler at 9-ea /Modules.java:366) [javadoc] at com.sun.tools.javac.comp.Modules.enter(jdk.compiler at 9-ea /Modules.java:210) [javadoc] at jdk.javadoc.internal.tool.JavadocTool.getEnvironment(jdk.javadoc at 9-ea /JavadocTool.java:190) [javadoc] at jdk.javadoc.internal.tool.Start.parseAndExecute(jdk.javadoc at 9-ea /Start.java:405) [javadoc] at jdk.javadoc.internal.tool.Start.begin(jdk.javadoc at 9-ea /Start.java:299) [javadoc] at jdk.javadoc.internal.tool.Start.begin(jdk.javadoc at 9-ea /Start.java:243) [javadoc] at jdk.javadoc.internal.tool.Main.execute(jdk.javadoc at 9-ea /Main.java:63) [javadoc] at jdk.javadoc.internal.tool.Main.main(jdk.javadoc at 9-ea /Main.java:52) [javadoc] javadoc: error - fatal error On Mon, Jun 20, 2016 at 4:18 PM, Kumar Srinivasan < kumar.x.srinivasan at oracle.com> wrote: > Hello, > > Please review the changes to fix: > https://bugs.openjdk.java.net/browse/JDK-8159305 > > The webrev is here: > http://cr.openjdk.java.net/~ksrini/8159305/webrev.00/ > > The spec-diff is here for reference: > http://cr.openjdk.java.net/~ksrini/8159305/spec-diff/overview-summary.html > > > Thanks > Kumar > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kumar.x.srinivasan at oracle.com Tue Jun 21 17:28:59 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 21 Jun 2016 10:28:59 -0700 Subject: RFR: 8159305: Enhance the javadoc tool to support module related options In-Reply-To: References: <576879C5.3020306@oracle.com> Message-ID: <5769795B.4070407@oracle.com> Hi Martin, No this does address the 166 issues, bug still open, https://bugs.openjdk.java.net/browse/JDK-8152911 This enhancement, makes it easy for folks to generate javadocs in a module centric manner. To give you an example, in the existing tool, you would do something like -modulesourcepath some-paths java.lang java.util java.io .... ie. packages that constitutes the module java.base So now with these enhancements you can simply do this: -modulesourcepath somepaths --module java.base--expand-requires:public Which will walk the module-graph documenting those modules and packages that meet the criteria. HTH Kumar > Hi Kumar, > > Is this intended to address the jsr166 use case (source files belong > to a module, but not the entire module is being processed, and not all > module sources are in a single tree)? > > Currently, jsr166 CVS docs are still broken. "ant docs" fails with > > [javadoc] java.lang.AssertionError > [javadoc] at > com.sun.tools.javac.util.Assert.error(jdk.compiler at 9-ea/Assert.java:155) > [javadoc] at > com.sun.tools.javac.util.Assert.checkNull(jdk.compiler at 9-ea/Assert.java:54) > [javadoc] at > com.sun.tools.javac.code.Symtab.enterModule(jdk.compiler at 9-ea/Symtab.java:755) > [javadoc] at > com.sun.tools.javac.comp.Modules.enterModule(jdk.compiler at 9-ea/Modules.java:262) > [javadoc] at > com.sun.tools.javac.comp.Modules.enterModules(jdk.compiler at 9-ea/Modules.java:240) > [javadoc] at > com.sun.tools.javac.comp.Modules.enter(jdk.compiler at 9-ea/Modules.java:208) > [javadoc] at > com.sun.tools.javac.main.JavaCompiler.readSourceFile(jdk.compiler at 9-ea/JavaCompiler.java:816) > [javadoc] at > com.sun.tools.javac.main.JavaCompiler.readSourceFile(jdk.compiler at 9-ea/JavaCompiler.java:778) > [javadoc] at > com.sun.tools.javac.main.JavaCompiler.access$100(jdk.compiler at 9-ea/JavaCompiler.java:97) > [javadoc] at > com.sun.tools.javac.main.JavaCompiler$1.complete(jdk.compiler at 9-ea/JavaCompiler.java:339) > [javadoc] at > com.sun.tools.javac.code.ClassFinder.fillIn(jdk.compiler at 9-ea/ClassFinder.java:362) > [javadoc] at > com.sun.tools.javac.code.ModuleFinder.lambda$findSingleModule$0(jdk.compiler at 9-ea/ModuleFinder.java:206) > [javadoc] at > com.sun.tools.javac.code.Symbol.complete(jdk.compiler at 9-ea/Symbol.java:602) > [javadoc] at > com.sun.tools.javac.comp.Modules.setCompilationUnitModules(jdk.compiler at 9-ea/Modules.java:366) > [javadoc] at > com.sun.tools.javac.comp.Modules.enter(jdk.compiler at 9-ea/Modules.java:210) > [javadoc] at > jdk.javadoc.internal.tool.JavadocTool.getEnvironment(jdk.javadoc at 9-ea/JavadocTool.java:190) > [javadoc] at > jdk.javadoc.internal.tool.Start.parseAndExecute(jdk.javadoc at 9-ea/Start.java:405) > [javadoc] at > jdk.javadoc.internal.tool.Start.begin(jdk.javadoc at 9-ea/Start.java:299) > [javadoc] at > jdk.javadoc.internal.tool.Start.begin(jdk.javadoc at 9-ea/Start.java:243) > [javadoc] at > jdk.javadoc.internal.tool.Main.execute(jdk.javadoc at 9-ea/Main.java:63) > [javadoc] at > jdk.javadoc.internal.tool.Main.main(jdk.javadoc at 9-ea/Main.java:52) > [javadoc] javadoc: error - fatal error > > > On Mon, Jun 20, 2016 at 4:18 PM, Kumar Srinivasan > > > wrote: > > Hello, > > Please review the changes to fix: > https://bugs.openjdk.java.net/browse/JDK-8159305 > > The webrev is here: > http://cr.openjdk.java.net/~ksrini/8159305/webrev.00/ > > > The spec-diff is here for reference: > http://cr.openjdk.java.net/~ksrini/8159305/spec-diff/overview-summary.html > > > > Thanks > Kumar > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Tue Jun 21 23:46:26 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 21 Jun 2016 16:46:26 -0700 Subject: RFR: 8154399, 8159096, export packages containing standard javadoc doclet In-Reply-To: <57636052.7070700@oracle.com> References: <57636052.7070700@oracle.com> Message-ID: <5769D1D2.8090909@oracle.com> Looks fine. /Erik On 2016-06-16 19:28, Jonathan Gibbons wrote: > Please review this simple fix for two related aspects of the same > problem: > > Export the "standard doclet" used by javadoc, such that it is possible > to derive alternative doclets, either by delegation or subtyping. > > In JDK 9, javadoc has a "new" standard doclet (JEP 221), but the old > one remains for compatibility, for the time being. Both should be > exported. > > > Jigsaw folk: > Please review the changes to jdk.javadoc module-info. > > Build folk: > The javadoc documentation is extended to include the documentation > for the package containing the new StandardDoclet. > (The API for the old StandardDoclet was never published in this > manner; it is only included in the javadoc tool guide, which remains > unchanged, for now.) > > javadoc folk: > The top level class for the new StandardDoclet is moved, without > any functional change, from an internal package to the new exported > package. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8154399 > https://bugs.openjdk.java.net/browse/JDK-8159096 > Webrev: http://cr.openjdk.java.net/~jjg/8154399/webrev.00 > > -- Jon