RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v3]

Ioi Lam iklam at openjdk.org
Fri Aug 22 17:24:18 UTC 2025


On Fri, 22 Aug 2025 14:07:43 GMT, Dan Heidinga <heidinga at openjdk.org> 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


More information about the hotspot-dev mailing list