RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile instance when dealing with unexpected Class-Path entry in manifest [v2]

[Jaikiran Pai]

On Sun, 25 Aug 2024 15:14:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>  For the bug report then it would be interesting to know if there is a plugin in the eco system that is creating the bad values or whether it's just a one-off.

I ran a test against the corpus. Of the 900K odd artifacts, only 2 jar files exhibited the issue where they had a `Class-Path` value which was malformed (resulting in a `MalformedURIException`).

Of those 2, one was due to what appears to be a user error - the Maven jar plugin allows for a `classpathPrefix` attribute which can be configured to use a custom prefix for each of the entries that will be added as a value to the `Class-Path` attribute (imagine prefixing each entry with `lib/`). In this case, it appears that this value was configured with an absolute path (`C:/Users/foo/.m2/repository/....`). As for the other jar with the malformed Class-Path, it's not clear how it was generated.

As for the specific project which reported this issue, this appears to be an isolated test specific utility which seems to be generating that malformed entry in one of the test jar files. It looks like it has been this way for several years. It's unclear to me what changed in that project recently which might have exposed this leak.

So this looks like a very rare case and isn't something that is generated generically by some plugin. When the `URLClassPath` detects such malformed `Class-Path` entries in a jar, then it ignores that jar. So if such entries were more common, then I think we would have seen complaints that would have said that `foo.jar` (which consists of a malformed `Class-Path` in its manifest) isn't being used to serve resources even when it is part of the classpath.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20691#issuecomment-2309355016