Integrated: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath

Eirik Bjørsnøs eirbjo at openjdk.org
Sat Jan 31 23:33:19 UTC 2026


On Sat, 17 Jan 2026 21:56:05 GMT, Eirik Bjørsnøs <eirbjo at openjdk.org> wrote:

> Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`.
> 
> The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first.
> 
> By splitting these two concerns and processing  loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`.
> 
> Advantages:
> 
> * A "hello world" Java program no longer  loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup using a directory class path)
> * One data structure is simpler than two
> * We no longer need to manage search path URLs across two different collections 
> * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed
> * I think this PR leaves the code overall simpler and easier to follow.
> 
> Testing:
> 
> This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage.

This pull request has now been integrated.

Changeset: ca95e5f3
Author:    Eirik Bjørsnøs <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ca95e5f3ddd5961dd43f825ed6c47054284c6798
Stats:     248 lines in 2 files changed: 205 ins; 20 del; 23 mod

8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath

Reviewed-by: liach, redestad, jpai

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

PR: https://git.openjdk.org/jdk/pull/29288


More information about the core-libs-dev mailing list