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

Retrofitting null-safety onto Java at Meta

engineering.fb.com

Post reply on HN
Print view View original

191–200 of 230 posts

Re: Retrofitting null-safety onto Java at Meta

#191

Post by Retric »

eternalban wrote: post #187
Retric wrote: post #186

Earlier quoted context omitted.

What else would you suggest for the falling popularity of Java from it’s mid 2000’s peak? Some of this is just fads, but I think languages tend to suit the time period when they are most popular. In 1990 C was a hugely dominant force because it suited the kinds of programs being written and the hardware available. IMO Java was a great compromise for late 90’s hardware, but different tradeoffs are becoming more useful…

My perception: There were waves. First wave of leaving Java was for RoR. Then there was a period where we had all these JVM languages, with Scala, JRuby, & finally Closure. Then a bit later came Go, which is when I switched. So why. First wave was due to the god awful experience of building web apps on app-servers. Remember how tedious that was? I forget the names, but there were so many frameworks. And of course imo…

That’s fair. I would add the Oracle acquisition of Sun and subsequent missteps shouldn’t be ignored. There was a huge wave of negative publicity and uncertainty which played off of the perception of being the new COBOL with a helping of factory.factory_endless_boilerplate_word_salid.

Java’s fragmentation also didn’t help as even just web technology evolution though Applets, Servlets, JavaBeans, Spring, JSF etc without letting people settle into something that just worked reasonably cleanly. The perception was always that there was tons of legacy options and sometimes multiple hot new fads creating an endless treadmill where working on the same thing for 4 years left you behind the curve rather than a productive environment.

By comparison .Net benefited from the second mover advantage. Embrace, Extend, Extinguish didn’t work but uniformity brought it’s own advantages and they could always copy and tweak something when it was clearly better.

Finally, there was a perception that the kind of companies using Java where exactly the kind of companies that would soon outsource jobs to India or just underpay and replace everyone with H1B’s.

Re: Retrofitting null-safety onto Java at Meta

#192

Post by Nullabillity »

za3faran wrote: post #183
Nullabillity wrote: post #169

Earlier quoted context omitted.

You could have had the Loom experience 20 years ago by just spawning OS threads. Of course, there's a reason that this was discouraged... threads quickly turn into a nightmare to manage safely, especially when they need to interact.

Genuine question, how is managing cross interacting virtual threads any different or easier than managing interacting threads? I say this and I am greatly looking forward to using Loom in production. It's definitely the correct way to go as opposed to async/await.

It's not. That's the problem with the thread API that Loom is so dead set on preserving, and the big improvement that promises/async/await provide over threads.

Re: Retrofitting null-safety onto Java at Meta

#193

Post by wizofaus »

masklinn wrote: post #78
mrkeen wrote: post #28

Earlier quoted context omitted.

It may have been hoped for, but it was an unrealistic hope. They couldn't have fixed it while retaining backward compatibility.

> They couldn't have fixed it while retaining backward compatibility. Opt-ins exist. That's what .net ended up doing: by default the language uses "ubiquitous" nullability, but you can enable reference nullability support at the project or file level. If you do that, references become non-nullable, and have to be explicitly marked as nullable when applicable.

The smart thing that C# has though is automatic conversion to non-nullable references, e.g.:

    void foo1(Bar bar)
    {
    ...
    }

    void foo2(Bar? bar)
    {
        if (bar != null)
            foo1(bar);   
    }
Which wouldn't compile if you didn't have the `if` condition.

Re: Retrofitting null-safety onto Java at Meta

#194

Post by chlorion »

StevePerkins wrote: post #146
hn_throwaway_99 wrote: post #117

Earlier quoted context omitted.

I have definitely come to the conclusion, especially after doing a lot of work in Typescript, that class Optional is a big mistake, whether from the JDK or other libraries that preceded it. First, because exactly the type of code that the parent commenter showed. I've actually seen this in production code (and shrieked). The fact is that without language-level support, you can end up getting the worst of all worlds.…

I miss the pre-Rust days. When Haskell was HN's cool pet language, and you had to obtain at least some vague familiarity with the term "monad" to understand half the discussion threads here. I'm sorry, but I don't think you understand the purpose that "Optional" was intended to serve. And are unduly dismissive simply because it does not serve some larger purpose that was not intended.

Yeah the concept of an Optional type is just too complex for other less advanced beings than yourself to understand.

Having the Optional class be nullable is actually genius and makes perfect sense, they are just not bright enough to see it!

Re: Retrofitting null-safety onto Java at Meta

#195

Post by mrcrumb1 »

Traubenfuchs wrote: post #69

I have been writing Java for money for more than ten years and never ever have I had non-trivial problems with null. Less than one percent of the bugs I fixed were caused by nullpointers, less than one percent of write-deploy-test loops were caused by it. I either have code that can't be null (e.g. getters of lists that create a list if the field is null, outright validation before usage), code where null has a desir…

If only there were a language feature that could tell you which case it was and ensure you handled it correctly...

Re: Retrofitting null-safety onto Java at Meta

#196

Post by hedora »

pron wrote: post #31
driggs wrote: post #21

It's so sad that Java 8 had the chance to really fix the null problem, but gave us only the half-assed `java.util.Optional `. Rather than implementing optional values at the language level, it's just another class tossed into the JRE. This is perfectly legal code, where the optional wrapper itself is null: Optional getMiddleName() { return null; }

What do you mean by had a chance? That chance isn't gone. This area is under investigation, and when we have a solution we like, we'll implement it. We can't address all issues at once. Optional isn't half-assed because it was never envisioned as a general solution to the null problem. It's simply an interface that's useful in streams and other similar cases for method return values, and it does the job it was intend…

> Optional isn't half-assed because it was never envisioned as a general solution to the null problem. It's simply an interface that's useful in streams and other similar cases for method return values, and it does the job it was intended to do reasonably well.

Regardless of the intent, once it got into the hands of enterprisey java devs, it immediately got used in two ways:

Tri-value nulls: treating null, None and Some in different ways.

Annotation hell: spam nullabilty annotations like @Nonnull Optional haphazardly everywhere with no semblance of soundness in sight.

When actually used as intended (by the 90 percentile coders on the team), it just bludgeons the GC to death because the JIT does not always do the right thing and elide the extra heap indirections.

They’re almost as bad an idea as type erasure!

Re: Retrofitting null-safety onto Java at Meta

#197

Post by sixbrx »

brabel wrote: post #45

We've been using `@Nullable` as Meta does in our code base for many years now (everything else is assumed to be non-null). Initially, we had CheckerFramework actually doing the checks at compile time... but eventually had to remove it because it's unstable, slow, has not kept up with Java evolution (we're on JDK 17, I think Checker still barely works on JDK 11) and also, because our IDE can be configured to flag erro…

Checker framework works fine on JDK 17 since not long after the release

Re: Retrofitting null-safety onto Java at Meta

#198

Post by Retric »

pron wrote: post #189
Retric wrote: post #185

Earlier quoted context omitted.

This isn’t just me, the language’s popularity has been steadily falling from a peak in the mid 2000’s. You can quibble about specific numbers, but the overall trend seems to be languages peak and then slowly fade, and Java is following Fortran, Pascal, and C as languages that simply aren’t keeping up with the shifting demands of the modern workforce. Ex: https://youtu.be/UNSoPa-XQN0

Java's mid 2000 peak was anomalous, not just for Java, but for any language. I can't think of a language (maybe C in the 80s?) ever dominating so much of the market. The market is now much more fragmented. What you should be asking is, which language is doing better? JS and Python are the only candidates. No single language is currently posed to take its place (although PHP and Ruby came closest), and no language out…

Several languages had similar levels of dominance. Fortran was even more dominant in the late 1960’s, then C in the early 90’s followed by Java in the 2000’s all had clear dominance.

It’s possible though harder to verify if Pascal reached that level and we might see Python hitting it soon.

Re: Retrofitting null-safety onto Java at Meta

#200

Post by AtNightWeCode »

Deukhoofd wrote: post #74
AtNightWeCode wrote: post #60

Earlier quoted context omitted.

C# have taking it further. New projects give errors if you don't declare vars as nullable when they may be null in some context. It will help for static analyzers to find these cases. I see a big risk in it. That people will just init nonsense objects to get around the warnings.

> That people will just init nonsense objects to get around the warnings. You technically can do "= null!", which means assign null by default, but assume it is not null. This is currently the recommended way to do deserialization, where you know the value is not null, but you have not explicitly filled it.

No, you get a nullable warning for that as well. You also need to change the reference type to nullable. I am convinced that some people will just init the properties with new(). And by that hide the null errors. Easily the hardest bugs to track down is when things fails long after the real error occur. I think they could have come with a better solution to the problem.
Post reply on HN