Rendered at 13:15:24 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
17 hours ago [-]
cogman10 17 hours ago [-]
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.
debugnik 16 hours ago [-]
That's a separate series of JEPs known as "final means final", also starting to land nowadays.
There's a jdk.internal API which will work as an escape hatch, but that does come with the need for non-compliant libraries to switch over to it. That safety hatch also only allows the setting of final fields once before observation (which is generally fine). So if your code is doing something more esoteric that sets a final field multiple times you will be SOL.
In any case, if you are using the sun.misc.Unsafe methods for setting final and private fields you'll need to update.
kasperni 17 hours 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 17 hours 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;
}
vips7L 17 hours 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 16 hours 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.
pjmlp 7 hours 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 13 hours 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.
well_ackshually 14 hours ago [-]
>particularly around serialization/marshaling
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.
vips7L 13 hours ago [-]
I swapped to Avaje Jsonb a while ago. Can’t recommend it and the rest of the Avaje libraries enough, especially Ebean instead of Hibernate.
exabrial 13 hours ago [-]
This a much needed change. Glad to see it! Might be some headaches in the short term, but thats ok.
joe_mwangi 16 hours ago [-]
Also, this will be used for future null-restricted types.
rvcdbn 17 hours ago [-]
oracle planning a new jvm language? have we ever seen a feature like this that is explicitly not usable from Java?
cogman10 16 hours ago [-]
> 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.
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.
https://openjdk.org/jeps/500
There's a jdk.internal API which will work as an escape hatch, but that does come with the need for non-compliant libraries to switch over to it. That safety hatch also only allows the setting of final fields once before observation (which is generally fine). So if your code is doing something more esoteric that sets a final field multiple times you will be SOL.
In any case, if you are using the sun.misc.Unsafe methods for setting final and private fields you'll need to update.
This particularly matters when you have something likes this
or even something like thisNope, 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.
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.
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.
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.