←back to thread

JEP draft: Prepare to make final mean final

(openjdk.org)
204 points mfiguiere | 6 comments | 31 Mar 25 19:35 UTC | HN request time: 0.996s | source | bottom
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 #
cogman10 ◴[01 Apr 25 02:15 UTC] No.43542139[source]▶
I can attest to how easy it's become to update jdks for our org.

8->11 was really a pain in the neck. 11->17 had some pain, but mostly was nothing serious.

17->21 has been painless.

And I have some projects running on 24 already with no problems.

The feature delivery has been great and we are getting pretty close to not needing to do anything but update the jdk to move forward.

Now, if only I could get devs to stop using lombok....

replies(5): >>43542341 #>>43542997 #>>43543123 #>>43543525 #>>43545478 #
pests ◴[01 Apr 25 05:23 UTC] No.43543123[source]▶
Been a long time since I used Java. I checked out lombok since you mentioned it. Does it really just internally create all those methods without there being actual source code? It seems nice but really spooky-action-at-a-distance feeling. Sounds like a nightmare.
replies(2): >>43543364 #>>43544494 #
elchananHaas ◴[01 Apr 25 06:09 UTC] No.43543364[source]▶
Yes, from a language design it's ugly and the implementation is convoluted. From a user perspective it's awesome and enables better interfaces.
replies(1): >>43543412 #
pests ◴[01 Apr 25 06:18 UTC] No.43543412[source]▶
I don't even agree with their demo video. It shows the "hard" way of autogenerating settings/getters, toString, hash, etc. The end result was like an additional ~80 boilerplate lines. I have no problem keeping those lines around.. opposed to adding the lombak.jar and changing my build config. I do understand the user perspective of it "just working" and of course the getters/setters will grow as you add fields... it just seems like such a low amount of code to keep around it shouldnt be too much hassle.
replies(3): >>43544698 #>>43545333 #>>43545504 #
lucumo ◴[01 Apr 25 11:04 UTC] No.43545333[source]▶
The problem isn't the first-time generating the code. The problem is when objects gain fields and people forget to add them to hashCode and equals (or worse, hashCode OR equals). It's the kind of thing you won't notice until months later when you have intermittent hard to debug glitches in your system.

Records have reduced the advantages of Lombok by a boatload. But there still are some things that can't be records.

replies(1): >>43545489 #
xxs ◴[01 Apr 25 11:29 UTC] No.43545489[source]▶
>add them to hashCode and equals (or worse, hashCode OR equals)

That's a fundamental misunderstanding of hashCode, and lombok makes no exception. Not all fields need to be used to calculate hashCode, it makes the overall performance worse in most cases. Equals is of course different, however if you have an identity (i.e. database primary key), only the identity should be used.

replies(2): >>43545743 #>>43555032 #
cogman10 ◴[01 Apr 25 12:05 UTC] No.43545743[source]▶
Hurray! I thought I was the only one that understood this. There are two of us!

I've seen so many performance issues with hashcode because devs will put all fields into it. Even though there's an id column or even fields that imply other fields. Hashing 1000 char strings when there's a UUID or int field that guarantees identity is silly.

I think it's because devs have an preference for symmetry. I see the same thing happen when they preferably add setters for all fields even though they aren't necessary.

replies(1): >>43546828 #
1. xxs ◴[01 Apr 25 13:55 UTC] No.43546828[source]▶
>There are two of us!

Realistically, I have trained quite a few folks on my own.

>I think it's because devs have an preference for symmetry.

Another option is that's the default for all IDEs auto gen, so few clicks/taps and it's done.

replies(1): >>43549334 #
2. ivan_gammel ◴[01 Apr 25 17:23 UTC] No.43549334[source]▶
In Idea you have to explicitly select the fields which should be included. So it’s always choice of a developer to misuse it.

My favorite question on interviews is explaining all methods of class Object, including the contract and best practices for equals/hashCode. Failure to answer this question automatically disqualifies applicants to mid-level and senior positions.

replies(1): >>43550608 #
3. xxs ◴[01 Apr 25 19:39 UTC] No.43550608[source]▶
>all methods of class Object

  finalize() is actually is a very hard mode; I'd not expect any extra senior to be able to explain it properly (incl. the semantics of JMM, the fact half created objects can be finalized; the resurrection ability). Deprecated now, so perhaps no need?
  wait/notify/notifyAll - easier, still require some practice, also not that useful any longer; but still I'd expect to know not to use a naked notify and how to properly use a loop around wait
  clone() - it'd be a hard nut for many, and I have seen more than enough implementations that straight out use new XXX(); not very difficult but not intuitive
  hashCode/equals -> hashCode being by default a random number generator is sort of cool; yes they are the backbone of all collection framework; also the value of the not overridden hashCode() is available through System.identifyHashCode()
  getClass() - if included anonymous classes, it might puzzle some
  toString() - finally something easy
---

flip note: the standard templates for intellij could use some work when it comes to the quality of hashCode;

replies(2): >>43551835 #>>43564439 #
4. ivan_gammel ◴[01 Apr 25 22:07 UTC] No.43551835{3}[source]▶
> finalize() is actually is a very hard mode;

> Deprecated now, so perhaps no need?

Yes. Worth mentioning existence and “do not touch it”, but no need to go deep. Same with clone. The point of this exercise is to demonstrate that you can use the core library without shooting yourself in the foot. As for wait/notify/notifyAll, I’d expect the correct usage patterns from mid-level.

5. vips7L ◴[03 Apr 25 03:37 UTC] No.43564439{3}[source]▶
> the standard templates for intellij could use some work when it comes to the quality of hashCode;

Doesn't everyone just use Objects::hash?

replies(1): >>43565723 #
6. xxs ◴[03 Apr 25 06:50 UTC] No.43565723{4}[source]▶
>Doesn't everyone just use Objects::hash?

I hope they do know better, it's actually rather poor. 1st it should not be used for a single parameter - just use hashCode() directly and ensure non-null in the c-tor (or Objects.hashCode). Then, in general you need - only few fields to calc a decent high cardinality hashCode...

Last: 31 as a constant (used in most mul/add schemas by java). It's a single byte prime, so it has some benefits. It can be implemented via shift and add (x<<5 - x) but modern CPUs implement mul quite well and don't have carry flag deps so shift+add is worse in general. However, as a constant is more like to cause collisions in a general purpose hash function. It's close to being power of 2 and multiple of 10 -> 32 and 30.