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.

▲ cogman10 7 hours ago | parent [-]

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;
    }

▲

vips7L 7 hours ago | parent [-]

Extremely easy to fix. Turn it into a record. I’m also pretty sure that cracking final fields is already disabled by default.

▲

cogman10 6 hours ago | parent [-]

> Extremely easy to fix.

Nope, if the deserializer is initializing that field by directly setting values both by the field and by the internals of the field, it'll be a problem. The fix is to update the deserializer to a newer version. Apache Fury recently fixed this very issue, but it still relies on internal JDK APIs in order to do it's work.

> I’m also pretty sure that cracking final fields is already disabled by default.

Nope. There's sun.misc.Unsafe apis that allow for cracking and modifying those final fields. There are new jdk.internal APIs for doing the same that you'd have to move over to in order to accomplish the same. This JEP is about making final (mostly) meaning final. At very least, it will enforce that final once observed is final with the internal APIs allowing a final field to be set once, just outside the constructor.

	▲	vips7L 3 hours ago \| parent [-]
		> sun.misc.Unsafe Yeah idk man sounds like it sucks to suck in this case. Don’t use unsafe. From your example: record Local(LocalDate ld) {} Will work perfectly fine with every deserializer I’ve ever seen.