2013/10/15 Stefan Bodewig <bode...@apache.org>:
> 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
>>  -Xdoclint                        Enable recommended checks for
>> problems in javadoc comments
>>  -Xdoclint:(all|none|[-]<group>)
>>        Enable or disable specific checks for problems in javadoc comments,
>>       where <group> 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
 * <p/>
   ^

EnhancedPatternLayout.java:86: error: tag not allowed here: <th>
   <th>Conversion Character</th>
   ^

XMLLayout.java:47: error: invalid entity &data;
  &nbsp;&nbsp;&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

Reply via email to