JEP draft: Prepare to make final mean final

(openjdk.org)

207 points mfiguiere | 4 comments | 31 Mar 25 19:35 UTC | HN request time: 0.829s | source

Show context

immibis ◴[02 Apr 25 09:23 UTC] No.43554960[source]▶

I don't see the point in putting another guard rail behind the override that's supposed to remove all guard rails. Java doesn't even have a security model any more, so what are you protecting?

Programmers from their own mistakes? That's fine, but this is about cases where they set the "I really mean it and this isn't a mistake" flag.

The JVM's optimized code from programmers? Plausible, but aren't there already many cases where things get deoptimized based on run-time state changes?

It feels like someone just said "final means final!" without really thinking about the purpose of a JVM. Will there be a proposal to enforce checked exceptions, too?

replies(2): >>43555151 #>>43555584 #

1. pjmlp ◴[02 Apr 25 11:26 UTC] No.43555584[source]▶

>>43554960 #

Yes it does, all of this is to make Java fully safe by default, in the age of cybersecurity laws, hence all loopholes are being closed down, in reflection, JNI and Panama.

The security model was deprected, just like .NET dropped CAS in .NET Core, because it wasn't sound, and without applets, the OS security model was the right way.

replies(1): >>43566910 #

2. immibis ◴[03 Apr 25 09:04 UTC] No.43566910[source]▶

>>43555584 (TP) #

If there's no security model then who are you protecting from who?

replies(1): >>43567314 #

3. pjmlp ◴[03 Apr 25 09:58 UTC] No.43567314[source]▶

>>43566910 #

There is the OS security model, who said otherwise?

Supply chain attacks from misbehaving libraries using reflection or JNI/Panama, that is what secure by default is protecting from.