←back to thread

JEP draft: Prepare to make final mean final

(openjdk.org)
204 points mfiguiere | 5 comments | 31 Mar 25 19:35 UTC | HN request time: 1.236s | source
Show context
cogman10 ◴[31 Mar 25 20:56 UTC] No.43539883[source]▶
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
    class Foo {
      final String bar;
    }
That'd allow me to transition code by just adding an annotation where it needs to be while also getting the benefit that final is really final everywhere else in code that isn't working with serialization.
replies(4): >>43540109 #>>43540145 #>>43541506 #>>43542330 #
owlstuffing ◴[01 Apr 25 00:21 UTC] No.43541506[source]▶
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 between them largely illusory. Integrity, as framed here, is ultimately binary.

The unfortunate reality of the "integrity by default" crusade is that applications relying on libraries and tools that modify internals will continue to do so. The JDK hasn’t filled any gaps—it has only made an already delicate situation worse.

replies(3): >>43541774 #>>43541788 #>>43542336 #
pron ◴[01 Apr 25 01:07 UTC] No.43541788[source]▶
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, although, as you say, it can be selectively allowed. And yet, between JDK 17 and JDK 23, changes of similar magnitude to the JDK internals caused nearly no upgrade problems. Upgrading the JDK now is smoother and easier than it's been in the last two decades. Why? Because there's been a large reduction in libraries' access to internals.

I think Java's handling of this transition compares very favourably to how other languages have handled similar transitions from some old model to a new one (or evolution in general) in terms of balancing the needs of both old and new projects.

replies(2): >>43542139 #>>43553477 #
1. Supermancho ◴[02 Apr 25 03:45 UTC] No.43553477[source]▶
> First, it's not a "crusade" but the steps necessary to deliver the features Java's users demand

Semantics. Nobody demanded anything, if we want to play word games.

The java philosophy of final, makes software less extensible. This is the point; to have less overriding. Regardless of what the voting body decides (the meaning of users being subtly repurposed), the feature is anti-developer-agency past the point of healthy balance. I dont understand the enthusiasm.

replies(2): >>43555021 #>>43556008 #
2. samus ◴[02 Apr 25 09:37 UTC] No.43555021[source]▶
Final making software less extensive is a red herring. The JEP is about final for fields, not final for classes. Nothing changes regarding the latter. It merely deprecates facilities that enable programmers to ignore the explicitly stated intentions of other developers.
replies(1): >>43558065 #
3. pron ◴[02 Apr 25 12:43 UTC] No.43556008[source]▶
> Nobody demanded anything, if we want to play word games.

People asked for lightweight concurrency, better FFI, faster startup, value classes etc.. How could we have done any of that without the integrity work? It's like saying, nobody asked you to make noise and dust to lay down cable ducts, we just asked for fast internet.

> The java philosophy of final, makes software less extensible. This is the point; to have less overriding. Regardless of what the voting body decides (the meaning of users being subtly repurposed), the feature is anti-developer-agency past the point of healthy balance.

There's absolutely no capability that this JEP removes (also, you seem to be confusing final classes/methods with final fields). All it does is say that the minority of programs that want to mutate final fields just have to tell the JVM about it so that it won't apply some future optimisation. Nothing is being taken away.

The JEP is: if you're mutating finals, you can continue to do so; if you're not -- you'll eventually get better performance. What's not to like?

4. Supermancho ◴[02 Apr 25 15:51 UTC] No.43558065[source]▶
> enable programmers to ignore the explicitly stated intentions of other developers

You say ignore. This is unnecessarily pejorative. You mean "change".

Software does not care about explicit intentions or who is leveraging it. Overriding is one of the essential methods of extending software.

replies(1): >>43558405 #
5. pron ◴[02 Apr 25 16:23 UTC] No.43558405{3}[source]▶
Java allows you to freely change any decision made by any author of any library you use. None of that ability has been taken away.

However, changing other code (and potentially changing the assumptions on which it was built) shouldn't be as easy as using it in a way that preserves its assumptions. If it were just as easy, you could accidentally break other code's assumptions.

In some situations, all that's required of you is merely to declare that you indeed intend to change some other code's assumptions; in more involved situations (e.g. a library method computes the sum of its argument and you want to change it to compute the product) the work is more involved, but you can still do it relatively easily.

What we have blocked is the ability of a library to change the assumptions of another library or of the application's without the application knowing about it. A library absolutely must not be allowed to do that while hiding that from the application.