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.
kasperni•26m ago
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•17m ago
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;
}
rvcdbn•14m ago
oracle planning a new jvm language? have we ever seen a feature like this that is explicitly not usable from Java?
cogman10•30m ago
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.
kasperni•26m ago
cogman10•17m ago
This particularly matters when you have something likes this
or even something like this