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

61–70 of 143 posts

Re: JEP draft: Prepare to make final mean final

#61

Post by exabrial »

hyperpape wrote: post #54
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.

Serialization is unfortunately important though... want to suspend a program and resume it later, or transfer it over a network, etc. The real world is kinda a let down.

Re: JEP draft: Prepare to make final mean final

#62

Post by LadyCailin »

pron wrote: post #60
LadyCailin wrote: post #59

Earlier quoted context omitted.

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

So make the flag remove some other feature, which is critical to production, like the ability to run main() or something.

On the other hand, I don’t think the solution to someone holding a shotgun to their foot and threatening to pull the trigger is to make everyone wear armored shoes. They’re already a lost cause, and there are a billion other ways they can shoot their foot off, if they are so inclined.

I agree with the principal of making it hard to screw things up assuming good faith efforts (making it hard to fall in the pit of despair), so overall I like the JEP.

Re: JEP draft: Prepare to make final mean final

#64

Post by cesarb »

steveklabnik wrote: post #26
eastbound wrote: post #16

Earlier quoted context omitted.

So how should GSON initialize an object? The theory is, go through the constructor. However, some objects are designed to go through several steps before reaching the desired state. If GSON must deserialize {…, state:”CONFIRMED”}, it needs to call new Transaction(account1, account2, amount), then .setState(STARTED) then .setState(PENDING) then .setState(PAID) then .setState(CONFIRMED) ? That’s the theory of the const…

> So how do we do it now? The JEP says: > the developers of serialization libraries should serialize and deserialize objects using the sun.reflect.ReflectionFactory class, which is supported for this purpose. Its deserialization methods can mutate final fields even if called from code in modules that are not enabled for final field mutation. I don't know enough about the details here to say if that's sufficient, but…

> The JEP says: [...]

The JEP also says:

> The sun.reflect.ReflectionFactory class only supports deserialization of objects whose classes implement java.io.Serializable.

In my experience, most classes being deserialized by libraries like GSON do not implement Serializable. Implementing Serializable is mostly done by classes which want to be serialized and deserialized through Java's native serialization format (which is used by nothing outside Java, unlike cross-platform formats like JSON or CBOR).

Re: JEP draft: Prepare to make final mean final

#65

Post by pron »

LadyCailin wrote: post #62
pron wrote: post #60

Earlier quoted context omitted.

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

So make the flag remove some other feature, which is critical to production, like the ability to run main() or something. On the other hand, I don’t think the solution to someone holding a shotgun to their foot and threatening to pull the trigger is to make everyone wear armored shoes. They’re already a lost cause, and there are a billion other ways they can shoot their foot off, if they are so inclined. I agree with…

> On the other hand, I don’t think the solution to someone holding a shotgun to their foot and threatening to pull the trigger is to make everyone wear armored shoes.

I don't think so, either, it's just that I think there are better solutions than a test-mode flag at the level of the `java` launcher. If the mechanism that runs the tests can automatically configure the appropriate capabilities without requiring the user running the tests to do manual configuration then the problem is solved for those who just want to easily run tests just as well as a test-mode configuration.

The idea of a test-mode flag has been floated before and considered; we're not ruling it out, but if such a mode is ever added, I can't tell you now what it would mean exactly. In any event, it's better to carefully study the nature of the problem and its origins before suggesting a particular solution. As Brian Goetz likes to say, today's solutions may well become tomorrow's problems.

> They’re already a lost cause, and there are a billion other ways they can shoot their foot off, if they are so inclined.

True, but our experience shows that it's not a good idea to make the bad choice the easiest one, or people may pick it out of laziness. Let those who want to shoot themselves in the foot work for it. If nothing else, it increases the chance that they learn what their (not-entirely-trivial) configuration means, and maybe they'll realise they don't want it after all.

Someone might point out that there are still ways to do the wrong thing out of laziness by blindingly copying a configuration from StackOverflow etc., but we're not done yet.

Re: JEP draft: Prepare to make final mean final

#67

Post by owlstuffing »

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…

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.

Re: JEP draft: Prepare to make final mean final

#68

Post by dapperdrake »

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…

This approach is surprisingly (or unsurprisingly) one of the most robust.

Re: JEP draft: Prepare to make final mean final

#70

Post by twic »

owlstuffing wrote: post #67
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…

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…

Not in my experience. I run my applications with default integrity, and when i hit a problem, i find out what caused it, and fix it. Often it's just a matter of upgrading a library to a newer version which doesn't do naughty reflective things, or changing some config to stop it doing so, or changing our own code. We had a serialisation library which did deep reflection to be slightly more efficient at serialising BigDecimal; there was a system property to turn that off, so i set it. We had code doing deep reflection into JMX to get the current PID; i changed it to use ProcessHandle instead. My colleague wrote a little test data library which does some horrific things; i might delete it and adopt Instacio instead.

I think there's only one case where i ended up relaxing integrity, and i'm hoping that's temporary - it will take more time to fix than i was willing to spend.

Post reply on HN