JEP 539: Strict Field Initialization in the JVM moved to preview

cogman10•about 3 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•about 2 hours ago

That's a separate series of JEPs known as "final means final", also starting to land nowadays.

https://openjdk.org/jeps/500

cogman10•about 2 hours ago

I believe these 2 are effectively linked.

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•about 2 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•about 2 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•about 2 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.

joe_mwangi•about 1 hour ago

Also, this will be used for future null-restricted types.

rvcdbn•about 2 hours ago

oracle planning a new jvm language? have we ever seen a feature like this that is explicitly not usable from Java?

cogman10•about 1 hour 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.

hueho•about 2 hours ago

It's a VM feature - value classes will use it when they land eventually. https://openjdk.org/projects/valhalla/

Skinney•about 2 hours ago

This is required in order to implement value classes in Java (project valhala).

JEP 539: Strict Field Initialization in the JVM moved to preview

⚡ Community Insights

Discussion (12 Comments)Read Original on HackerNews