P4
URLClassPath currently uses an ArrayDeque for its unopenedUrls dequeue.
The motivation for using a double-ended queue seems to be that "original" path URLs are added to the tail of the queue while any "discovered" loader class path URLs are added to the head.
URLClassPath is the only client of ArrayDeque in a "hello world" Java program, so causes loading of ArrayDeque, Deque and Queue during startup.
An additional concern is how URLClassPath delicately dances around calling ArrayDeque#addAll or new ArrayDeque(Collection) to avoid calling into lambdas.
If we handle original path and loader-discovered URLs in separate lists, we no longer need a double-ended queue and can use plain ArrayLists instead.
Besides avoiding additional class loading, this also simplifies the current code a bit and also allows any loader-discovered list to be created lazily.
The motivation for using a double-ended queue seems to be that "original" path URLs are added to the tail of the queue while any "discovered" loader class path URLs are added to the head.
URLClassPath is the only client of ArrayDeque in a "hello world" Java program, so causes loading of ArrayDeque, Deque and Queue during startup.
An additional concern is how URLClassPath delicately dances around calling ArrayDeque#addAll or new ArrayDeque(Collection) to avoid calling into lambdas.
If we handle original path and loader-discovered URLs in separate lists, we no longer need a double-ended queue and can use plain ArrayLists instead.
Besides avoiding additional class loading, this also simplifies the current code a bit and also allows any loader-discovered list to be created lazily.
- links to
-
Review(master)
openjdk/jdk/29288