3

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?

stiemannkj1
  • 4,418
  • 3
  • 25
  • 45
  • Take a look at the behavior of AOT compilers like Graal. – boneill Oct 18 '21 at 22:26
  • @boneill, I don’t believe reflection works in AOT compilers like Graal (although I could be mistaken), so I think the point would be moot there since there’s probably no safe way to check if `Optional` is available. I’m not really worried about AOT for this question though. – stiemannkj1 Oct 18 '21 at 22:29
  • Your question ends with "...will never be loaded?" So, the reason I suggested AOT compilers is because all classes are effectively loaded in advance. Perhaps the question needs to be clarified a bit. – boneill Oct 19 '21 at 05:26
  • @stiemannkj1 "*I don’t believe reflection works in AOT compilers like Graal*" - At least for GraalVM, this is not true. [GraalVM supports reflection](https://www.graalvm.org/reference-manual/native-image/Reflection/), although some additional configuration might be required. – Turing85 Oct 19 '21 at 12:37

1 Answers1

5

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.

Holger
  • 285,553
  • 42
  • 434
  • 765