[
https://issues.apache.org/jira/browse/LOG4J2-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032252#comment-16032252
]
Ralph Goers edited comment on LOG4J2-1925 at 6/1/17 12:34 AM:
--------------------------------------------------------------
No, javadoc doesn't parse English. But it does require a full sentence in the
method description so it will look for a period. For some reason it allows
other words after that first sentence and they don't have to end with a period.
My suggestion would be to create an annotation processor that does nothing and
include that on the classpath. If that fails then it is not a problem with
Log4j.
was (Author: [email protected]):
No, javadoc doesn't parse English. But it does require a full sentence in the
module description so it will look for a period. For some reason it allows
other words after that first sentence and they don't have to end with a period.
My suggestion would be to create an annotation processor that does nothing and
include that on the classpath. If that fails then it is not a problem with
Log4j.
> Having log4j-core on the compile classpath somehow breaks compilation even if
> I'm not calling it
> ------------------------------------------------------------------------------------------------
>
> Key: LOG4J2-1925
> URL: https://issues.apache.org/jira/browse/LOG4J2-1925
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.7, 2.8.2
> Environment: Oracle JDK 8
> Reporter: Trejkaz
> Priority: Blocker
>
> Background: Almost a week ago, our build started breaking with weird errors
> on Javadoc. Initially only one user and the build machine were seeing it, but
> it gradually spread and now happens for everyone on the team.
> Yesterday I spent most of the day investigating it and have cut it down to a
> fairly minimal project, which I uploaded here:
> https://github.com/trejkaz/gradle_wtf_compile
> The project name does contain "gradle" because at the time we had assumed
> Gradle was to blame. However, this has since been removed from the list of
> potential culprits, and all that's left now is log4j and javac itself. Given
> that Oracle are near to useless at fixing even critical bugs, I figured
> reporting it here would be a good next step in case it turns out to be
> log4j's fault.
> Basically, if I have code like this:
> {code:java}
> /**
> * Example utility class.
> */
> public class Utils
> {
> /**
> * Does stuff
> *
> * @throws Exception if an error occurs.
> */
> public static void checkProject1() throws Exception
> {
> // empty
> }
> // ...
> }
> {code}
> And I try to build the code:
> {code:sh}
> mkdir -p build/classes/main
> javac -source 1.8 -target 1.8 -d build/classes/main \
> -classpath
> $HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-core/2.8.2/979fc0cf8460302e4ffbfe38c1b66a99450b0bb7/log4j-core-2.8.2.jar:$HOME/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.8.2/e590eeb783348ce8ddef205b82127f9084d82bf3/log4j-api-2.8.2.jar
> \
> -Xlint:all,-serial -Xdoclint:all,-missing \
> src/main/java/com/acme/Utils.java
> {code}
> I get an error:
> {noformat}
> src/main/java/com/acme/Utils.java:13: error: invalid use of @throws
> * @throws Exception if an error occurs.
> ^
> src/main/java/com/acme/Utils.java:23: error: invalid use of @throws
> * @throws RuntimeException if an error occurs.
> ^
> src/main/java/com/acme/Utils.java:33: error: invalid use of @throws
> * @throws IOException if an error occurs.
> ^
> 3 errors
> {noformat}
> The error message supposedly occurs when the thing you provided is not an
> exception, but that is not the case at all.
> If I remove log4j-core from the classpath, compilation succeeds. If I remove
> -Xdoclint from the command-line, that dodges the problem during javac, but
> then javadoc fails later in the build, so it isn't a solution.
> I have many questions...
> 1. How does just having this one jar on the classpath somehow break
> compilation when I'm not even calling it?
> 2. How is it that we are the first ones to encounter this? I'm seeing it on
> literally every platform, and have tested multiple versions of Java 8 that I
> had on hand, and all of them behaved the same way. Maybe nobody is using Java
> 8 and log4j in the same project yet, but it seems a bit unlikely.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
