RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath
Claes Redestad
redestad at openjdk.org
Tue Jan 20 00:32:27 UTC 2026
On Mon, 19 Jan 2026 22:42:35 GMT, Eirik Bjørsnøs <eirbjo at openjdk.org> wrote:
>> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 212:
>>
>>> 210: return;
>>> 211: synchronized (searchPath) {
>>> 212: if (! searchPath.contains(url)) {
>>
>> Does it matter that this would now search through all opened URLs while before we'd only scan through the list of unopened? I guess you'd need something like `!searchPath.subList(nextURL, searchPath.size() + 1).contains(url)` to be perfectly neutral semantically here, but I'm not sure if re-adding previously opened URLs is a valid use-case.
>
> Hello Claes!
>
>> Does it matter that this would now search through all opened URLs while before we'd only scan through the list of unopened?
>
> Not sure I follow. If by "scan through" you mean the `contains` call, then we scan through the same list of URLs before and after this PR. It's the list of URLs passed in the constructor, possibly amended by calls to `addURL`. It was renamed from `path` to `searchPath`.
>
> Whether URLs had been loaded or not did not matter before this PR, and it does not matter now. Before we needed to add URLs to both `unopenedUrls` (to find it during loading) and to `paths` (because we needed to return the amended list in `getURLs`.
>
> The only change in this `addURL` method (besides renaming) is that we no longer need to update `unopenedUrls`. This is because `nextURL` now looks for URLs first in `expandedPath`, then directly in `searchPath`. Before, URLs were processed strictly from `unopenedUrls` and the only purpose of having the `path` field seems to have been `getURLs`.
>
> Perhaps I misunderstood what you're saying here.. Could you also re-read the code and check that you got it right on your side?
>
> We should definitely get to the bottom of this, we don't want to introduce any behavior changes in this PR, should be a pure refactoring.
Yeah, I simply misread. What you have seems fine.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2706381466
More information about the core-libs-dev
mailing list