Is it specified in the JVM/JLS that classes in unused code paths will never be loaded?

Question

Given the following class using Java 8 Optional:

final class Main {
    public static void main(final String[] args) {
        System.out.println(Optional.of("test").get());
    }
}

If I compile the code with a Java 8 compiler targeting Java 7 bytecode:

javac -target 1.7 -source 1.7 Main.java

When I run with a Java 7 JVM, main throws a NoClassDefFoundError wrapping a ClassNotFoundException for java.util.Optional as expected.

However if I check for the availability of the Optional class (via reflection) prior to using it:

final class Main {
    public static void main(final String[] args) {
        if (isOptionalAvailable()) {
            System.out.println(Optional.of("test").get());
        } else {
            System.out.println("Optional not found.");
        }
    }

    private static boolean isOptionalAvailable() {
        try {
            Class.forName("java.util.Optional");
            return true;
        } catch (ClassNotFoundException e) {
            return false;
        }
    }
}

When I run with a Java 7 JVM, it does not throw any errors:

Optional not found.

What I’m trying to find out is if this behavior is required by the JVM or JLS specifications. It seems like the behavior is consistent across Oracle, IBM, and OpenJDK, but I couldn’t seem to find any requirements in the specs that classes used locally in methods must be lazily loaded.

I looked through "Chapter 5. Loading, Linking, and Initializing" of the JVM Spec and "15.12.4. Run-Time Evaluation of Method Invocation" in the JLS.

For my second example, could there be a JVM impl that eagerly loads Optional even though it only exists in an unused code path? Am I missing the section of the spec(s) that requires this behavior or is it just a common implementation detail?

Answer 1

There is no guaranty that the class doesn’t get loaded.

Consider JLS, §5.4:

This specification allows an implementation flexibility as to when linking activities (and, because of recursion, loading) take place, provided that all of the following properties are maintained:

…

For example, a Java Virtual Machine implementation may choose a "lazy" linkage strategy, where each symbolic reference in a class or interface (other than the symbolic references above) is resolved individually when it is used. Alternatively, an implementation may choose an "eager" linkage strategy, where all symbolic references are resolved at once when the class or interface is being verified.

Even the HotSpot JVM, which uses lazy class loading, may attempt to load the class earlier than expected, i.e. outside that unused code path, due to subtle aspects of the code, which may require the verifier to load a class, as discussed in When is a Java Class loaded?

In other words, even with this JVM implementation, small changes to the code may suddenly make it fail when the class is absent.