JEP 539: Strict Field Initialization in the JVM moved to preview

Post by cogman10 » Thu, Jul 02, 2026, 7:56 PM UTC

Post by cogman10 » Thu, Jul 02, 2026, 8:09 PM UTC

kasperni wrote: post #3

cogman10 wrote: post #2

This is a great change that will undoubtedly cause a lot of headaches. There's a number of libraries (particularly around serialization/marshaling) which will end up mutating `final` fields. In fact, this is a trick I've pulled once or twice in my own code for "reasons" (generally needing to modify behavior of a library because it was deficient). I suspect this will be one of those things that ends up requiring java…

Strict Field Initialization is opt-in. A flag needs to be set in the classfile in order to enable it. So should not effect any existing code.

    class Local {
       private final ThirdPartyObject tpo;
    }

    class Local {
      private final LocalDate ld;
    }

Post by [deleted] » Thu, Jul 02, 2026, 8:13 PM UTC

Post by vips7L » Thu, Jul 02, 2026, 8:31 PM UTC

cogman10 wrote: post #4

kasperni wrote: post #3

Earlier quoted context omitted.

Strict Field Initialization is opt-in. A flag needs to be set in the classfile in order to enable it. So should not effect any existing code.

It won't bite initially, it will bite when you go to update your version of javac in the future and this becomes the default. Or when you update a library that just so happened to be compiled with a newer version of javac. This particularly matters when you have something likes this class Local { private final ThirdPartyObject tpo; } or even something like this class Local { private final LocalDate ld; }

Post by debugnik » Thu, Jul 02, 2026, 8:48 PM UTC

cogman10 wrote: post #2

This is a great change that will undoubtedly cause a lot of headaches. There's a number of libraries (particularly around serialization/marshaling) which will end up mutating `final` fields. In fact, this is a trick I've pulled once or twice in my own code for "reasons" (generally needing to modify behavior of a library because it was deficient). I suspect this will be one of those things that ends up requiring java…