JEP draft: Prepare to make final mean final

Post by pron » Tue, Apr 01, 2025, 1:07 AM UTC

owlstuffing wrote: post #67

cogman10 wrote: post #21

Hmm, not a bad approach. I think the one thing that'd be nice is if I could somehow tell the JVM from a class that this class is open for final mutation rather than needing special flags passed into the JVM or special manifests in the Jar. It's often pretty clear to me, as a dev, what I when I need something to have final mutation (generally only with serialization objects). For example, @FinalMutatableByReflection c…

The issue is that many essential libraries and tools rely on setting internal final fields. I assume that's why the options around this have remained open-ended. The problem with these various "integrity by default" options is that, in most cases, granting access to one effectively grants access to all. For instance, JNI, agent libraries, and JPMS options can each be used to bypass restrictions, making the separation…

Post by recursivecaveat » Tue, Apr 01, 2025, 1:27 AM UTC

twic wrote: post #72

eastbound wrote: post #16

Earlier quoted context omitted.

So how should GSON initialize an object? The theory is, go through the constructor. However, some objects are designed to go through several steps before reaching the desired state. If GSON must deserialize {…, state:”CONFIRMED”}, it needs to call new Transaction(account1, account2, amount), then .setState(STARTED) then .setState(PENDING) then .setState(PAID) then .setState(CONFIRMED) ? That’s the theory of the const…

It strikes me that we could have a way to reflectively create an object from values for all its fields in a single step - similar to what record constructor does, but for any class (could even be Class::getCanonicalConstructor, returning a java.lang.reflect.Constructor). It would be equivalent to creating an uninitialised instance and then setting its fields one by one, but the partly-initialised object would never b…

Post by cogman10 » Tue, Apr 01, 2025, 2:15 AM UTC

pron wrote: post #71

owlstuffing wrote: post #67

Earlier quoted context omitted.

The issue is that many essential libraries and tools rely on setting internal final fields. I assume that's why the options around this have remained open-ended. The problem with these various "integrity by default" options is that, in most cases, granting access to one effectively grants access to all. For instance, JNI, agent libraries, and JPMS options can each be used to bypass restrictions, making the separation…

First, it's not a "crusade" but the steps necessary to deliver the features Java's users demand. Second, the prevalence of the use of JDK internals has dropped drastically, and demonstrably so. For example, many programs broke before internals were encapsulated during the upgrade from 8 to 9; 99% of the causes were libraries relying on internals, which had changed. Access to internals was closed off in JDK 16, althou…

Post by sgammon » Tue, Apr 01, 2025, 2:52 AM UTC

owlstuffing wrote: post #67

cogman10 wrote: post #21

Hmm, not a bad approach. I think the one thing that'd be nice is if I could somehow tell the JVM from a class that this class is open for final mutation rather than needing special flags passed into the JVM or special manifests in the Jar. It's often pretty clear to me, as a dev, what I when I need something to have final mutation (generally only with serialization objects). For example, @FinalMutatableByReflection c…

The issue is that many essential libraries and tools rely on setting internal final fields. I assume that's why the options around this have remained open-ended. The problem with these various "integrity by default" options is that, in most cases, granting access to one effectively grants access to all. For instance, JNI, agent libraries, and JPMS options can each be used to bypass restrictions, making the separation…

Post by dstine » Tue, Apr 01, 2025, 3:03 AM UTC

hyperpape wrote: post #54

exabrial wrote: post #44

I'm 100% onboard with this. My thought was how are they going to make Serialization work, but looks like they thought of that. I was trying to think of an edge case with JsonB or JAXB that would be affected by this... but generally those frameworks have told you for quite awhile not to do stupid stuff like: ``` @Getter public class HelloMessage { @JsonbProperty private final String helloMessage; } ``` I can't think o…

Brian Goetz, chief architect of Java, once posted a "what they think I do" vs. "what I actually" do tweet. If I remember correctly, 25% - 50% of the "what I actually do" category was something like "get angry at serialization." So I think it's safe to say "what about serialization?" is always going to be asked.