JEP draft: Prepare to make final mean final • Hacker News Board

Re: JEP draft: Prepare to make final mean final

#31

Post by TOGoS » Mon, Mar 31, 2025, 9:22 PM UTC

> Application developers can avoid both current warnings and future restrictions by selectively enabling the ability to mutate final fields where essential.

/me raises hand

Maybe if you want to mutate a field, don't mark it `final`?

I know, I know, people like to pretend things are one way and then hand their objects over to some horrid framework that breaks all the rules, because apparently giant web of mutable spaghetti is just fine, not an anti-pattern at all if you let some third-party bull$#!7 ORM/dependency-injection-framework-for-people-who-don't-like-constructors do it.

Re: JEP draft: Prepare to make final mean final

#32

Post by nightpool » Mon, Mar 31, 2025, 9:24 PM UTC

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…

They actually have a very similar proposal in the draft already:

    The sun.reflect.ReflectionFactory class only supports deserialization of objects whose classes implement java.io.Serializable

That is, you'll still be able to mutate final fields using the ReflectionFactory class, as long as that class inherits from Serializable

Re: JEP draft: Prepare to make final mean final

#33

Post by PhilipRoman » Mon, Mar 31, 2025, 9:25 PM UTC

jjmarr wrote: post #4

From my perspective as a C++ developer, every attempt to use `const` for compiler optimization appears to be stymied by the existence of `const_cast`, because modifying a `const` value is only undefined behaviour if the underlying object is `const`. Glad to see that Java is willing to break the language to improve it.

The implementation of "const" in C/C++ is really annoying, in the end all you get is a bit of semantic documentation and a bunch of compiler errors or casts whenever some library doesn't use it. You can often trick the compiler into stronger optimizations by making a local variable marked as "const" (in which case it is a "true const") and copying the value to/from it.

Re: JEP draft: Prepare to make final mean final

#34

Post by Misdicorl » Mon, Mar 31, 2025, 9:26 PM UTC

nightpool wrote: post #30

[Speculative optimizations] may not suffice in this case as future planned optimizations may wish to rely not only on immutability within the lifetime of the process, but also on the immutability of fields from one run of the application to the next. Can someone elaborate a little more on what this means? I'm very surprised to hear that this was considered a blocker important enough to add all of this complicated mac…

I suppose serializing the JVM state itself to avoid the cold start problem might take advantage of this?

Re: JEP draft: Prepare to make final mean final

#35

Post by mb7733 » Mon, Mar 31, 2025, 9:26 PM UTC

oconnor663 wrote: post #24

mb7733 wrote: post #17

Earlier quoted context omitted.

> modifying a `const` value is only undefined behaviour if the underlying object is `const`. I found this sentence confusing. You mean that modifying a value that has been const_cast is undefined behaviour only if the original variable was const right? Or something else?

(Rereading your comment, it sounds like you might already know all of this. Apologies.) If I understand correctly, here's a C++ example that has undefined behavior: int foo() { const int x = 42; int *p = (int *)&x; *p += 1; return x; } foo() is UB, because it modifies the const object x, using a pointer cast to "cast away const". (Unfortunately, UBSan doesn't catch this, and I'm not aware of any sanitizer that does.)…

Right, gotcha, I just found it confusing to say "modifying a `const` value" but if course you meant modifying the underlying value [through a cast]. All good.

Re: JEP draft: Prepare to make final mean final

#36

Post by neonsunset » Mon, Mar 31, 2025, 9:30 PM UTC

.NET went through a similar change, blocking `static readonly` fields from being accessible via private reflection. Unfortunately, a lot of serializers and all sorts of meta-programming libraries depend on (mutable) private reflection of instance fields still so for now they are not blocked and JIT cannot treat them as truly immutable, turning into JIT constants the way it does so for static readonly fields. Although I guess you can always make a struct and place it into a static readonly, where each field could be such JIT constant (within certain limits).

Re: JEP draft: Prepare to make final mean final

#37

Post by bdangubic » Mon, Mar 31, 2025, 9:35 PM UTC

vips7L wrote: post #19

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…

Why would you use GSON for objects that go through steps of state? Why would you mark fields like State as final when it is actually mutable? This just sounds like poorly designed code. Maybe I don't know of your use case, but GSON/Jackson/Json type classes are strictly data that should only represent the data coming over the wire. If you need to further manipulate that data it sounds like the classes have too much r…

all state is immutable :) a change creates new state - which is immutable

Re: JEP draft: Prepare to make final mean final

#38

Post by vips7L » Mon, Mar 31, 2025, 9:35 PM UTC

bdangubic wrote: post #37

vips7L wrote: post #19

Earlier quoted context omitted.

Why would you use GSON for objects that go through steps of state? Why would you mark fields like State as final when it is actually mutable? This just sounds like poorly designed code. Maybe I don't know of your use case, but GSON/Jackson/Json type classes are strictly data that should only represent the data coming over the wire. If you need to further manipulate that data it sounds like the classes have too much r…

all state is immutable :) a change creates new state - which is immutable

:) no its not.

Re: JEP draft: Prepare to make final mean final

#39

Post by nightpool » Mon, Mar 31, 2025, 9:44 PM UTC

Misdicorl wrote: post #34

nightpool wrote: post #30

[Speculative optimizations] may not suffice in this case as future planned optimizations may wish to rely not only on immutability within the lifetime of the process, but also on the immutability of fields from one run of the application to the next. Can someone elaborate a little more on what this means? I'm very surprised to hear that this was considered a blocker important enough to add all of this complicated mac…

I suppose serializing the JVM state itself to avoid the cold start problem might take advantage of this?

Why would that prevent the JVM from using the same speculative optimization JIT with deoptimization hooks approach?

Re: JEP draft: Prepare to make final mean final

#40

Post by GauntletWizard » Mon, Mar 31, 2025, 9:44 PM UTC

When I had the brief displeasure of working on HDFS at Facebook, we took a series of customer meetings to figure out how to get our oldest customers to upgrade their clusters. I was in a meeting with the photos team about what their requirements were and what was blocking them from upgrading, and they were very frank - they asked if the upgrade preserved the internal struct types associated with blocks on the disc servers. They didn't actually use hdfs as a file system, they allocated 1 GB files with zero replication, then used deep reflection to find the extent that comprised them on the discful storage servers, then built their own archival backup file system on top of that. I was horrified. The some of the older hats on the team were less surprised, having had some inkling of what was going on, even though they clearly didn't understand the details. Others considered it tantamount to sacrilege.

I think about this a lot. What they had built was probably actually the best distributed file system within Facebook. It was similarly structured to unraid, and had good availability, durability, and space saving properties, but the approach to engineering was just so wrong headed in my opinion that I couldn't stomach it. Talking about it with other Java programmers within facebook, nobody seemed to mind. Final was just a hint after all.