[jira] [Updated] (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
]
Falko Modler updated MCHECKSTYLE-377:
-
Description:
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}}.
was:
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 C
[jira] [Updated] (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
]
Falko Modler updated MCHECKSTYLE-377:
-
Description:
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 and it also
might affect more than just {{@throws}}.
was:
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
[jira] [Updated] (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
]
Falko Modler updated MCHECKSTYLE-377:
-
Summary: Violations or exceptions when using "external" FQCNs in @throws
after upgrade to 3.1.0 (was: Violations or exceptions when using FQCNs in
@throws after upgrade to 3.1.0)
> 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)
>
