[Closed] (MCHECKSTYLE-377) Violations or exceptions when using "external" FQCNs in @throws after upgrade to 3.1.0

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[Closed] (MCHECKSTYLE-377) Violations or exceptions when using "external" FQCNs in @throws after upgrade to 3.1.0

Elliotte Rusty Harold (Jira)

     [ https://issues.apache.org/jira/browse/MCHECKSTYLE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Elliotte Rusty Harold closed MCHECKSTYLE-377.
---------------------------------------------

> Violations or exceptions when using "external" FQCNs in @throws after upgrade to 3.1.0
> --------------------------------------------------------------------------------------
>
>                 Key: MCHECKSTYLE-377
>                 URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-377
>             Project: Maven Checkstyle Plugin
>          Issue Type: Bug
>    Affects Versions: 3.1.0
>         Environment: Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T21:00:29+02:00)
> Java version: 1.8.0_202, vendor: Oracle Corporation
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>            Reporter: Falko Modler
>            Priority: Major
>
> I started to see strange violations and even exceptions after upgrading checkstyle-plugin from 3.0.0 and 3.1.0. Please note that I pinned Checkstyle to 8.7, so the Checkstyle version itself did _not_ change in my setup.
> The problem boils down to Checkstyle not being able anymore to load classes that reside in dependencies (= not im the same project as the checked class) when using fully qualified class names in {{@throws}} tags, e.g.:
> {code:java}
>     /**
>      * Foo.
>      * @throws some.other.project.SomeException some exception.
>      */
>     public void foo() throws SomeException {
>         // ...
>     }
> {code}
> Please note that the actual throws declaration does _not_ use the fully qualified class name.
> While this might be an inconsistent/non DRY approach, it is not forbidden by JavaDoc or the compiler.
> In one case (where the exception resides in an external dependency), this resulted in a violation:
> {noformat}
> JavadocMethod: Expected @throws tag for 'SomeException'.
> {noformat}
> In another case (where the exception resides in the same module but implements an interface that resides in another module of the project being built), this resulted in an exception:
> {noformat}
> [...]
> Caused by: java.lang.NoClassDefFoundError: some/project/othermodule/SomeInterface
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
>         at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>         at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
>         at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:348)
>         at com.puppycrawl.tools.checkstyle.checks.javadoc.ClassResolver.safeLoad(ClassResolver.java:216)
>         at com.puppycrawl.tools.checkstyle.checks.javadoc.ClassResolver.resolve(ClassResolver.java:95)
>         at com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.resolveClass(AbstractTypeAwareCheck.java:241)
>         at com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.tryLoadClass(AbstractTypeAwareCheck.java:258)
>         at com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck$RegularClass.getClazz(AbstractTypeAwareCheck.java:467)
>         at com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.checkThrowsTags(JavadocMethodCheck.java:909)
>         at com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.checkComment(JavadocMethodCheck.java:503)
>         at com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.processAST(JavadocMethodCheck.java:357)
>         at com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.visitToken(AbstractTypeAwareCheck.java:157)
>         at com.puppycrawl.tools.checkstyle.TreeWalker.notifyVisit(TreeWalker.java:423)
>         at com.puppycrawl.tools.checkstyle.TreeWalker.processIter(TreeWalker.java:579)
>         at com.puppycrawl.tools.checkstyle.TreeWalker.walk(TreeWalker.java:363)
>         at com.puppycrawl.tools.checkstyle.TreeWalker.processFiltered(TreeWalker.java:208)
>         at com.puppycrawl.tools.checkstyle.api.AbstractFileSetCheck.process(AbstractFileSetCheck.java:83)
>         at com.puppycrawl.tools.checkstyle.Checker.processFile(Checker.java:319)
>         at com.puppycrawl.tools.checkstyle.Checker.processFiles(Checker.java:289)
>         ... 25 more
> Caused by: java.lang.ClassNotFoundException: some.project.othermodule.SomeInterface
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>         ... 54 more
> {noformat}
> I guess this is caused by MCHECKSTYLE-353 (which does improve runtime a lot when {{checkstyle:check}} is invoked explicitly).
> *Workaround*: Don't use fully qualified exception class names in {{@throws}}.
> PS: This might actually be a shortcomming in Checkstyle itself and it also might affect more than just {{@throws}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)