You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Elliotte Rusty Harold (Jira)" <ji...@apache.org> on 2020/06/04 12:16:00 UTC
[jira] [Closed] (MCHECKSTYLE-377) Violations or exceptions when
using "external" FQCNs in @throws after upgrade to 3.1.0
[ 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)