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

51–60 of 143 posts

Re: JEP draft: Prepare to make final mean final

#51

Post by xxs »

no_wizard wrote: post #41
nightpool wrote: post #32

Earlier quoted context omitted.

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

Back in the '90s I used to consider sun.xxx the cooler version of Java.

Re: JEP draft: Prepare to make final mean final

#52

Post by xxs »

stickfigure wrote: post #3

Great! Now can we make `final` the default for all fields, variables, and parameters? (yes yes, I know, that would break syntax... but please come up with something to discourage mutability)

>but please come up with something to discourage mutability)

Records?

Re: JEP draft: Prepare to make final mean final

#53

Post by xxs »

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…

This is rather old[0] but still relevant.

Surprise #2! A popular open-source framework writes to final fields after object construction via generated bytecodes!... This optimization of the final field is *the* main optimization performed on final fields.

[0] https://web.archive.org/web/20121016082428/http://www.azulsy...

Re: JEP draft: Prepare to make final mean final

#54

Post by hyperpape »

exabrial wrote: post #44

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 o…

Brian Goetz, chief architect of Java, once posted a "what they think I do" vs. "what I actually" do tweet. If I remember correctly, 25% - 50% of the "what I actually do" category was something like "get angry at serialization."

So I think it's safe to say "what about serialization?" is always going to be asked.

Re: JEP draft: Prepare to make final mean final

#55

Post by ars »

Does this mean I should start marking my variables (and function parameters) with Final?

Up till now I always assumed the compiler would figure out on its own which variables were final, and optimize as needed. But this JEP makes it seem like there are optimizations that only happen if you manually mark the variable.

Re: JEP draft: Prepare to make final mean final

#56

Post by magicalhippo »

titzer wrote: post #25
magicalhippo wrote: post #7

Earlier quoted context omitted.

Const-ness in C++ is something I miss in other languages. Being immediate able to see that this function or method couldn't mutate the object made it so much easier to reason about the code. Yeah I know there's ways around it, but then the author known what they told the other party to expect.

If possible, 1) design completely immutable data structures that can be broadly shared and don't need to be copied. If you need mutability, just embrace the fact that someone is going to abuse mutability and 2) try to create abstractions that can suffer abuse. If you're coming from a language that doesn't have const, you learn to build things that are hard(er) to screw up. While bad code can exist in any language, I…

> sprinkling const all over the code to lock things down

That's like using a hammer on a screw, clearly not the right way.

Thankfully I've never worked on such codebases.

Re: JEP draft: Prepare to make final mean final

#57

Post by adrianmonk »

GauntletWizard wrote: post #40

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 se…

That reminds me of a quote from some Perl documentation[1]:

> Perl does not enforce private and public parts of its modules as you may have been used to in other languages like C++, Ada, or Modula-17. Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun.

It's not exactly the same situation, but the point is, at the end of the day, you need to be able to rely on the people involved being willing to act reasonable. If you can't, then you're going to have problems.

---

[1] https://perldoc.perl.org/perlmodlib

Re: JEP draft: Prepare to make final mean final

#59

Post by LadyCailin »

pron wrote: post #45
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…

Would be nice to have a single “--test-mode” flag that is only meant to be set when running tests, and allows for all this leniency, (add opens, etc) in a single flag.

Re: JEP draft: Prepare to make final mean final

#60

Post by pron »

LadyCailin wrote: post #59
pron wrote: post #45

Earlier quoted context omitted.

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…

Would be nice to have a single “--test-mode” flag that is only meant to be set when running tests, and allows for all this leniency, (add opens, etc) in a single flag.

We should separate the problem from the solution. The problem is that running tests may require relatively many integrity-busting flags. That is true.

There are, however, better solutions than a global test-mode flag that, invariably, will be used by some in production out of laziness, leaving no auditable record of what integrity constraints need to be violated and why. When a new team lead is appointed some years later they will have a hard time trying to reduce the entropy.

The better solutions will arrive in due course, but until then, build tools can automatically add most of the necessary flags. They should be encouraged to do that.

Post reply on HN