This is a follow up on the discussion about static inline fields and the risk of having a default value escaping while the inline class is uninitialized (the problematic scenario being when the class fails to initialize properly).
This situation already exists today, it is possible to produce it with this code for instance (the discussion continues after the code): import java.lang.reflect.InvocationTargetException; import java.lang.reflect.Method; public class UninitilizedClassTest { public static A a; public static boolean b = true; static class A { public int i; public Object o; static long l; static { UninitilizedClassTest.a = new A(); if (UninitilizedClassTest.b) { throw new Error(); } } static void static_print() { System.out.println("Hello!"); } void nonstatic_print() { System.out.println("i=" + i); } } public static void main(String[] args) { try { A test_a = new A(); } catch(Throwable t) { } System.out.println("Accessing instance fields"); System.out.println("a.o=" + a.o); System.out.println("Invoking non-static methods"); a.nonstatic_print(); System.out.println("Accessing static fields"); try { System.out.println("A.l=" + A.l); } catch (Throwable t) { t.printStackTrace(); } System.out.println("Invoking static methods"); Method m = null; try { m = a.getClass().getDeclaredMethod("static_print", null); } catch (NoSuchMethodException e) { e.printStackTrace(); } try { m.invoke(null); } catch (IllegalAccessException e) { e.printStackTrace(); } catch (InvocationTargetException e) { e.printStackTrace(); } } } This situation is known, and the way the JVM deals with it is: - access to the leaked instance (fields, methods) is fine - access to the static context of the class which failed to initialized properly (fields, methods, new) throws an exception Here’s the output of the program above: Accessing instance fields a.o=null Invoking non-static methods i=0 Accessing static fields java.lang.NoClassDefFoundError: Could not initialize class UninitilizedClassTest$A at UninitilizedClassTest.main(UninitilizedClassTest.java:36) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.intellij.rt.execution.application.AppMainV2.main(AppMainV2.java:131) Invoking static methods Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class UninitilizedClassTest$A at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at UninitilizedClassTest.main(UninitilizedClassTest.java:48) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.intellij.rt.execution.application.AppMainV2.main(AppMainV2.java:131) What is new with static inline fields? It just becomes simpler to produce this scenario. With regular classes, it requires a faulty static initializer to leak an instance to a publicly accessible place before the class initialization fails to complete. With static inline classes, any static inline field could potentially produce this situation. Do we want to provide more protection for inline classes than we actually provide for identity classes? The question is why? Should we provide compile time warnings? They are likely to generate a lot of false positive. Last time I’ve investigated this issue and discussed it with Alex Buckley, I came to the conclusion that it was not necessary to do additional work for inline classes. But the EG can have a different opinion. Fred