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.
> have we ever seen a feature like this that is explicitly not usable from Java?
Loads. Invoke dynamic and Nest-Based Access Control come to mind.
This sort of thing is also about tightening the VM specification so things like Valhala are possible. Value classes really can't function reasonably without strict field initialization. That's because these value classes can have multiple copies while an application is running. If there's a way to go in and tinker with the fields before, after, or during initialization it could lead to very hard to fix and debug issues. 1 object in 2 parts of the code with different field values.
And the reason for this tightening is because, from java, there are routes to violate this strict field initialization.
14 comments
[ 2.3 ms ] story [ 15.4 ms ] threadThere'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.
https://openjdk.org/jeps/500
The solution being to drop those dogshit reflection based libraries as everyone should have done 10 years ago when codegen became more common.
Looking at you, Gson.
Loads. Invoke dynamic and Nest-Based Access Control come to mind.
This sort of thing is also about tightening the VM specification so things like Valhala are possible. Value classes really can't function reasonably without strict field initialization. That's because these value classes can have multiple copies while an application is running. If there's a way to go in and tinker with the fields before, after, or during initialization it could lead to very hard to fix and debug issues. 1 object in 2 parts of the code with different field values.
And the reason for this tightening is because, from java, there are routes to violate this strict field initialization.
It was later used to implement lambda expressions but originally had no use in the Java language and isn't tailored to lambda expressions.
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...