[
https://issues.apache.org/jira/browse/LOG4J2-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16299597#comment-16299597
]
Trejkaz commented on LOG4J2-1925:
---------------------------------
Their reason was eventually, "because the workaround is easy - just turn off
doclint, or turn off annotation processing".
(Which is fine for us right now because we don't want annotation processing. If
we ever wanted to use Lombok or something, then we'd be in some real trouble.)
> 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
> Assignee: Ralph Goers
> 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.4.14#64029)
