Some XxxAccess instances in jdk.internal.access.SharedSecrets are initialized lazily on 1st access with the following idiom:

    public static JavaUtilJarAccess javaUtilJarAccess() {
        if (javaUtilJarAccess == null) {
            // Ensure JarFile is initialized; we know that this class
            // provides the shared secret
            ensureClassInitialized(JarFile.class);
        }
        return javaUtilJarAccess;
    }

But this idiom is flawed in concurrent setting. It may happen that the two reads of javaUtilJarAccess non-volatile field get reordered and so the 1st read (in if condition) reads non-null while the 2nd read (in return) reads null. This can be fixed by introducing a local variable that avoids the 2nd read:

    public static JavaUtilJarAccess javaUtilJarAccess() {
        var access = javaUtilJarAccess;
        if (access == null) {
            // Ensure JarFile is initialized; we know that this class
            // provides the shared secret
            ensureClassInitialized(JarFile.class);
            access = javaUtilJarAccess;
        }
        return access;
    }