gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: logging-log4j-12 failed
Date Tue, 15 Oct 2013 04:16:54 GMT
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.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message