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 devs everywhere to bump up the versions of the libraries they use.
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;
}
Weirdly enough, I encountered this once while writing code.
You can trigger it with a single class that initializes one field with a call to a static method of the same class.
And a second static field that is initialized by performing a computation on the first static field.
Here's a simplified example of the same - https://ashishb.net/programming/java/final-variable-with-two...
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 devs everywhere to bump up the versions of the libraries they use.
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
or even something like thisExtremely easy to fix. Turn it into a record. I’m also pretty sure that cracking final fields is already disabled by default.
oracle planning a new jvm language? have we ever seen a feature like this that is explicitly not usable from Java?
It's a VM feature - value classes will use it when they land eventually. https://openjdk.org/projects/valhalla/
This is required in order to implement value classes in Java (project valhala).