[
https://issues.apache.org/jira/browse/MCHECKSTYLE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MCHECKSTYLE-377:
-------------------------------------
Summary: Violations or exceptions when using FQCNs in @throws after upgrade
to 3.1.0 (was: Violations or exception when using FQCNs in @throws after
upgrade to 3.1.0)
> Violations or exceptions when using 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:
> com.t_systems_mms.ccs.common.base.service.exception.ExceptionAttributeInterface
> 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 (why does it
> try to _load_ that exception anyway?) and it also might affect more than just
> {{@throws}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
