On Fri, 22 Aug 2025 14:07:43 GMT, Dan Heidinga <[email protected]> wrote:
>> This code basically adds an entrypoint in the `SharedSecrets` class for
>> other JDK core lib classes to call into package-private API in this package.
>> It doesn't do anything else.
>>
>> There are several other classes where we have to do the same `SharedSecrets`
>> set-up.
>>
>>
>> @AOTRuntimeSetup
>> private static void runtimeSetup() {
>> SharedSecrets.setJavaNetURLAccess(
>> new JavaNetURLAccess() {
>> @Override
>> public URLStreamHandler getHandler(URL u) {
>> return u.handler;
>> }
>> }
>> );
>> }
>
> I'm less worried about this particular `runtimeSetup` implementation and more
> with what it implies. Namely that we have URL instances - with particular
> URLStreamHandlers associated with them - running around in the archived heap.
> If in production, a different URLStreamHandler is configured for a given
> URL, we'll get two different sets of validation logic for assembly time URLs
> vs production run URLs.
>
> Are we able to limit the protocols that we create URLs for? I'm reaching for
> some way to contain the potential issue to something smaller that we can
> reason about
I added a check that URLs can be cache only if they use the `file` and `jtr`
protocols, whose `URLStreamHandlers` cannot be overridden by the application.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294262042
