3 ms·

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

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 4mo ago
Extremely easy to fix. Turn it into a record. I’m also pretty sure that cracking final fields is already disabled by default.
- cogman10 4mo ago
  > 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 4mo ago
    > 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.
  - pjmlp 4mo ago
    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 4mo ago

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

cogman10 4mo ago
> 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 4mo ago
  > 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.
- pjmlp 4mo ago
  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.