[jira] [Commented] (LOG4J2-1925) Having log4j-core on the compile classpath somehow breaks compilation even if I'm not calling it

["Ralph Goers (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16160628#comment-16160628 ] 

Ralph Goers commented on LOG4J2-1925:
-------------------------------------

Oracle has closed JDK-8186647 as Won't Fix. No reason was given. However, they have verified that this bug does not occur in Java 9 and they verified that it occurs in the latest releases of Java 8.

> 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)