Re: logging-log4j-12 failed
2013/10/15 Stefan Bodewig : > On 2013-10-15, Ludmila Shikhvarg wrote: > >> Stefan Bodewig wrote: >>> On 2013-10-07, Ludmila Shikhvarg wrote: > > Hi, > > > I'm using JDK8 from https://jdk8.java.net/download.html to run gump. logging-log4j-12 is started to fail with b75 and onward (the build log is attached). Any ideas? > > > com.sun.tools.javac.code.Symbol$CompletionFailure: class file for sun.util.locale.provider.LocaleProviderAdapter not found com.sun.tools.doclets.internal.toolkit.util.DocletAbortException: com.sun.tools.javac.code.Symbol$CompletionFailure: class file for sun.util.locale.provider.LocaleProviderAdapter not found > > >>> Looks like a defect in javadoc to me - at least not like anything the >>> log4j devs would be able to fix. > >>> Stefan > >> The same exception seen before the failure. >> Heads up: >> javadoc -Xdoclint is a new feature in jdk8. Default behavior is on so >> that javadoc now issues warnings and errors and problems in javadoc >> comments in the source: > >> $ jdk8/bin/javadoc -X >> -XdoclintEnable recommended checks for >> problems in javadoc comments >> -Xdoclint:(all|none|[-]) >>Enable or disable specific checks for problems in javadoc comments, >> where is one of accessibility, html, missing, reference, >> or syntax. > >> You may choose to fix your javadoc comments, or to get backward >> compatible behavior with jdk7 use -Xdoclint:none. > > I'll forward this to the log4j developers. But I really don't think > this is an option. This is Java6: > > , > | $ javadoc -Xdoclint:none > | javadoc: error - invalid flag: -Xdoclint:none > ` > > so my build process would have to detect Java8 at runtime and pass > different arguments to javadoc based on it - this adds complexity. > > TBH I think it is a really bad idea to change defaults in a manner that > breaks the build processes of code that worked before. > > In addition the exception itself isn't really helpful as it doesn't say > what is wrong (at least I didn't see anything) but rather looks like a > bug in javadoc - that one can avoid to trigger. > Release notes for recently released JDK 7u45 mention that it fixes several security issues in the Javadoc tool: CVE-2013-5797, CVE-2013-5804 [1] It seems that general concern is that generated HTML may contain script code insertions. A logical extension to this would be that at some point Javadoc could become more strict on what HTML it processes. It might be what is currently happening with JDK8. (Just my guess). Besides usual warnings, the log attached to the first e-mail lists a number of HTML errors in those Javadoc comments, such as AsyncAppender.java:37: error: self-closing element not allowed * ^ EnhancedPatternLayout.java:86: error: tag not allowed here: Conversion Character ^ XMLLayout.java:47: error: invalid entity &data; &data; An exception among those errors (Symbol$CompletionFailure: class file for sun.util.locale.provider.LocaleProviderAdapter not found) should be a bug in the Javadoc tool itself, but it seems non-fatal, as other errors are reported after that. >From names of methods in the stack trace I guess that the error occurred when generating class summary part of some HTML page. I guess that page may be missing from generated Javadoc. [1] http://www.oracle.com/technetwork/topics/security/cpuoct2013verbose-1899842.html#JAVA (If anyone is interested, details on those issues fixed in JDK 7u45 are not yet available from Oracle or MITRE, but they can be found in RedHat bugzilla, https://access.redhat.com/security/cve/CVE-2013-5797 https://bugzilla.redhat.com/show_bug.cgi?id=1018720 https://access.redhat.com/security/cve/CVE-2013-5804 https://bugzilla.redhat.com/show_bug.cgi?id=1019131 ) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: logging-log4j-12 failed
On 2013-10-15, Ludmila Shikhvarg wrote: > Stefan Bodewig wrote: >> On 2013-10-07, Ludmila Shikhvarg wrote: >>> Hi, >>> I'm using JDK8 from https://jdk8.java.net/download.html to run gump. >>> logging-log4j-12 is started to fail with b75 and onward (the build log >>> is attached). >>> Any ideas? >>> com.sun.tools.javac.code.Symbol$CompletionFailure: class file for >>> sun.util.locale.provider.LocaleProviderAdapter not found >>> com.sun.tools.doclets.internal.toolkit.util.DocletAbortException: >>> com.sun.tools.javac.code.Symbol$CompletionFailure: class file for >>> sun.util.locale.provider.LocaleProviderAdapter not found >> Looks like a defect in javadoc to me - at least not like anything the >> log4j devs would be able to fix. >> Stefan > The same exception seen before the failure. > Heads up: > javadoc -Xdoclint is a new feature in jdk8. Default behavior is on so > that javadoc now issues warnings and errors and problems in javadoc > comments in the source: > $ jdk8/bin/javadoc -X > -XdoclintEnable recommended checks for > problems in javadoc comments > -Xdoclint:(all|none|[-]) >Enable or disable specific checks for problems in javadoc comments, > where is one of accessibility, html, missing, reference, > or syntax. > You may choose to fix your javadoc comments, or to get backward > compatible behavior with jdk7 use -Xdoclint:none. I'll forward this to the log4j developers. But I really don't think this is an option. This is Java6: , | $ javadoc -Xdoclint:none | javadoc: error - invalid flag: -Xdoclint:none ` so my build process would have to detect Java8 at runtime and pass different arguments to javadoc based on it - this adds complexity. TBH I think it is a really bad idea to change defaults in a manner that breaks the build processes of code that worked before. In addition the exception itself isn't really helpful as it doesn't say what is wrong (at least I didn't see anything) but rather looks like a bug in javadoc - that one can avoid to trigger. Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: logging-log4j-12 failed
Stefan Bodewig wrote: On 2013-10-07, Ludmila Shikhvarg wrote: Hi, I'm using JDK8 from https://jdk8.java.net/download.html to run gump. logging-log4j-12 is started to fail with b75 and onward (the build log is attached). Any ideas? com.sun.tools.javac.code.Symbol$CompletionFailure: class file for sun.util.locale.provider.LocaleProviderAdapter not found com.sun.tools.doclets.internal.toolkit.util.DocletAbortException: com.sun.tools.javac.code.Symbol$CompletionFailure: class file for sun.util.locale.provider.LocaleProviderAdapter not found Looks like a defect in javadoc to me - at least not like anything the log4j devs would be able to fix. Stefan The same exception seen before the failure. Heads up: javadoc -Xdoclint is a new feature in jdk8. Default behavior is on so that javadoc now issues warnings and errors and problems in javadoc comments in the source: $ jdk8/bin/javadoc -X -XdoclintEnable recommended checks for problems in javadoc comments -Xdoclint:(all|none|[-]) Enable or disable specific checks for problems in javadoc comments, where is one of accessibility, html, missing, reference, or syntax. You may choose to fix your javadoc comments, or to get backward compatible behavior with jdk7 use -Xdoclint:none. Regards, Ludmila - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: logging-log4j-12 failed
On 2013-10-07, Ludmila Shikhvarg wrote: > Hi, > I'm using JDK8 from https://jdk8.java.net/download.html to run gump. > logging-log4j-12 is started to fail with b75 and onward (the build log > is attached). > Any ideas? > com.sun.tools.javac.code.Symbol$CompletionFailure: class file for > sun.util.locale.provider.LocaleProviderAdapter not found > com.sun.tools.doclets.internal.toolkit.util.DocletAbortException: > com.sun.tools.javac.code.Symbol$CompletionFailure: class file for > sun.util.locale.provider.LocaleProviderAdapter not found Looks like a defect in javadoc to me - at least not like anything the log4j devs would be able to fix. Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
