[cogman10]

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]

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

[cogman10]

> 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.

[pjmlp]

sun.misc.Unsafe will eventually be no longer, plenty of methods have already been removed since safer alternatives were introduced.

Java isn't alone in this, as usual due to their relationship, .NET is also clamping down some of this stuff, including changing the memory model around unsafe code blocks.

There are other ecosystems for monkey patching.

[vips7L]

> 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.