[maven] Classloader not being closed after PMD run

[cwholmes]

Affects PMD Version:
Unknown: Definitely 6.18.0+

Rule:

Description:
Classloader is being constructed in the configuration and then never closed.

https://github.com/pmd/pmd/blob/master/pmd-core/src/main/java/net/sourceforge/pmd/PMDConfiguration.java#L196

This classloader is then never closed and is being left to be close the open jar file references when finalized. This seems to be keeping open file references to jarfiles. (Also duplicating them across threads).

Code Sample demonstrating the issue:

Example of classloader that isn't closed:

maven-pmd-plugin

Running PMD through: [Maven]

[adangel]

Inside PMD - meaning, when running PMD from commandline or via the provided ant task, there is no problem:

• For the ant task, we close it at the end:

  pmd/pmd-core/src/main/java/net/sourceforge/pmd/ant/internal/PMDTaskImpl.java

  Line 287 in d115ca5

  IOUtil.tryCloseClassLoader(configuration.getClassLoader());

• For CLI invocations, we close it here:

  pmd/pmd-core/src/main/java/net/sourceforge/pmd/PMD.java

  Line 265 in d115ca5

  IOUtil.tryCloseClassLoader(configuration.getClassLoader());

It seems, how the maven-pmd-plugin calls PMD, the classloader is not closed, though.

I'll keep this issue open, maybe we can improve the API, so that such situation is not even possible. The API caller shouldn't have to deal with that problem.

There might be a similar problem for the https://github.com/pmd/pmd-eclipse-plugin.

See also:

• https://issues.apache.org/jira/browse/MPMD-297
• https://issues.apache.org/jira/browse/MNG-6836

[adangel]

This is still open - we still use a classloader via PMDConfiguration, which needs to be closed.

This is not a problem, as long as PMD is used as described in https://pmd.github.io/latest/pmd_userdocs_tools_java_api.html.

But if PMD is used differently, or a PMDConfiguration is created without calling PmdAnalysis, then one might still run into this issue.

[jsotuyod]

@adangel so if I understand correctly, this lies 100% on the Maven plugin, that is tightly bound to PMD using it's internal APIs (part of the reason why the pmd-compat6 module was needed); with nothing to do on this end.

Do you want to keep it here? or do you have a corresponding issue on the Maven plugin's JIRA?

[adangel]

The closing part has been fixed in m-pmd-p 3.14.0 already.
As #4949 / #4899 showed, the classloader is definitely closed in maven-pmd-plugin still today. So, there is no problem in this regard anymore.

The only thing left here is:

I'll keep this issue open, maybe we can improve the API, so that such situation is not even possible. The API caller shouldn't have to deal with that problem.

That's an API problem: Whoever calls PMDConfiguration#prependAuxClasspath might create an Classloader, that might not be closed.

Right now, when calling PMD via PmdAnalysis, the classloader is closed when PmdAnalysis is closed. So, it should not be a problem anymore, if PmdAnalysis is closed.

However, I find it still surprising, that PMDConfiguration manages a classloader instead of a classpath...

Two things, I'd suggest:

1. document in the API for PMDConfiguration#prependAuxClasspath and the related methods (setClassloader, getClassloader) the implications of not properly closing the classloader.
2. deprecate setClassloader/getClassloader, refactor PMDConfiguration to deal with a list of strings (a "classpath") and create the classloader only later, fully internally and not exposing this classloader in any way.

[adangel]

Closing this one now in favor of #4952 and #4953.