Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JEP draft: Prepare to make final mean final

openjdk.org

Post reply on HN
Print view View original

41–50 of 143 posts

Re: JEP draft: Prepare to make final mean final

#41

Post by no_wizard »

nightpool wrote: post #32
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

I know this isn’t the most relevant but to see the sun namespace still exists gives me a small amount of joy

Re: JEP draft: Prepare to make final mean final

#42

Post by Misdicorl »

nightpool wrote: post #39
Misdicorl wrote: post #34

Earlier quoted context omitted.

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?

It wouldn't, but it might preclude using (future) optimizations that forgo those de-optimization hooks?

Re: JEP draft: Prepare to make final mean final

#43

Post by josephg »

steveklabnik wrote: post #28
recursive wrote: post #22

Earlier quoted context omitted.

> Even the JS standard library struggles with this. ... I don't think this represents struggling. There needs to be some way to sort in place. Sometimes you need to sort a big array and don't want to allocate. And there should be some way to clone the array without mutating. That's slice. So you how do you sort a clone? .slice().sort() I think by far the biggest problem with ES .sort() is that number arrays don't sor…

> There needs to be some way to sort in place. Sometimes you need to sort a big array and don't want to allocate Your parent isn't saying there shouldn't be mutation, just that the mutation should be obvious. In Rust, the type signature for the in-place sort is pub fn sort(&mut self) where T: Ord, That `&mut self` lets you know that it's going to mutate.

Exactly. And for function parameters, rust also (usually) makes it obvious when you’re passing by value, by reference or by mutable reference:

    foo(x); // Moves or copies
    foo(&x); // immutable reference
    foo(&mut x); // mutable reference
I don’t need to look up the signature of foo to understand what happens to my variable. It’s obvious at a glance.

Re: JEP draft: Prepare to make final mean final

#44

Post by exabrial »

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 of any frameworks offhand that do this.

Re: JEP draft: Prepare to make final mean final

#45

Post by pron »

bironran wrote: post #6

A cursory glance at "setAccessible" usage reveals popular libraries such as serializers like gson and jaxb, class manipulation and generation like cglib, aspectj and even jdk.internal.reflect, testing frameworks and libraries including junit, mockito and other mocking libraries, lombok, groovy, spring, and the list goes on and on. My bet is that this will be yet another "checked exception" or "module system", where m…

We've addressed that in the JEP. Serialization libraries have a special way to circumvent this (until we get Serialization 2.0), and mocking libraries may, indeed, need to set the flag, but they're rarely used in production, so if they don't enjoy some new optimisation -- no big deal.

BTW, this JEP does not apply to setAccessible generally, as that's been restricted since JDK 16, but only to the particular (and more rare) use of setAccessible to mutate instance final fields. As the JEP says, static final fields, records' internal instance fields, and final instance fields of hidden classes cannot be mutated with that approach currently, so it's never been something that's expected to work in all cases.

Re: JEP draft: Prepare to make final mean final

#46

Post by PaulHoule »

bironran wrote: post #6

A cursory glance at "setAccessible" usage reveals popular libraries such as serializers like gson and jaxb, class manipulation and generation like cglib, aspectj and even jdk.internal.reflect, testing frameworks and libraries including junit, mockito and other mocking libraries, lombok, groovy, spring, and the list goes on and on. My bet is that this will be yet another "checked exception" or "module system", where m…

My impression is that this will be painful for the code I work on because the libraries you mention depend on being able to modify private and/or final fields.

Re: JEP draft: Prepare to make final mean final

#48

Post by xxs »

PaulHoule wrote: post #46
bironran wrote: post #6

A cursory glance at "setAccessible" usage reveals popular libraries such as serializers like gson and jaxb, class manipulation and generation like cglib, aspectj and even jdk.internal.reflect, testing frameworks and libraries including junit, mockito and other mocking libraries, lombok, groovy, spring, and the list goes on and on. My bet is that this will be yet another "checked exception" or "module system", where m…

My impression is that this will be painful for the code I work on because the libraries you mention depend on being able to modify private and/or final fields.

private fields are no issue

Re: JEP draft: Prepare to make final mean final

#49

Post by pron »

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…

There's ongoing work, as part of Project Leyden, to cache certain computations -- either performed by the user code or the JVM -- from one run of the program to the next, including the caching of JIT-compiled machine code. The early parts of this work were discussed here: https://www.morling.dev/blog/jep-483-aot-class-loading-linki...

Re: JEP draft: Prepare to make final mean final

#50

Post by recursive »

josephg wrote: post #43
steveklabnik wrote: post #28

Earlier quoted context omitted.

> There needs to be some way to sort in place. Sometimes you need to sort a big array and don't want to allocate Your parent isn't saying there shouldn't be mutation, just that the mutation should be obvious. In Rust, the type signature for the in-place sort is pub fn sort(&mut self) where T: Ord, That `&mut self` lets you know that it's going to mutate.

Exactly. And for function parameters, rust also (usually) makes it obvious when you’re passing by value, by reference or by mutable reference: foo(x); // Moves or copies foo(&x); // immutable reference foo(&mut x); // mutable reference I don’t need to look up the signature of foo to understand what happens to my variable. It’s obvious at a glance.

Fair point. I guess this is the cost of dynamic languages.
Post reply on HN