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. Here's a simplified example of the same - https://ashishb.net/programming/java-musings-initializing-a-...
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 thisoracle planning a new jvm language? have we ever seen a feature like this that is explicitly not usable from Java?