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