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

181–190 of 230 posts

Re: Retrofitting null-safety onto Java at Meta

#181

Post by [deleted] »

tehlike wrote: post #112
pron wrote: post #106

Earlier quoted context omitted.

First of all, Java's generics are already superior to C#'s. We've exchanged the minor inconvenience of not being able to have overloads that erase to the same type with the ability to support multiple variance strategies rather than one that's baked into the runtime. That's why Java has Clojure and Kotlin and Scala and Ruby running on top of it with such great interop. And, as it turns out, when specialisation is rea…

"Java generics is superior to C#" - That's a first for me. C# generics don't have to do boxing of types like java does, and overall have much better type safety between library boundaries, etc...

[deleted]

Re: Retrofitting null-safety onto Java at Meta

#182

Post by guelo »

mrkeen wrote: post #167
guelo wrote: post #164

Earlier quoted context omitted.

@Nullable/@NotNull is great when the IDE shows the warnings, basically dev time checking. There are also tools to integrate it into your builds for compile time checking.

I get a little green tick in the top right of my IDE window with the following: @Test public void foo() { final Map map = new HashMap (); map.put("present", 1); bar(map.get("missing")); } void bar(@NotNull Integer param) { System.out.println(param); } "No problems found"

Right, that's because the system libraries don't have the annotations. That's the biggest issue with it. But it still helps a lot if you're religious about it in your own code.

Re: Retrofitting null-safety onto Java at Meta

#183

Post by za3faran »

Nullabillity wrote: post #169
krzyk wrote: post #143

Earlier quoted context omitted.

And saved millions of developer minds not having to deal with mind bending async/await. Thanks, I prefer to wait.

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.

Re: Retrofitting null-safety onto Java at Meta

#184

Post by za3faran »

mrkeen wrote: post #132
csunbird wrote: post #82

Earlier quoted context omitted.

isn't @NonNull just a syntactic sugar for adding checkNonNull() call as first statement to the function declaration in compile time, or am I mistaken? Just like lombok, it is supposed to generate code that checks null arguments, from what I know.

I tried: @Test public void foo() { bar(null); } void bar(@NonNull String param) { System.out.println(param); } All versions of that annotation let the null right through. I tried with: import lombok.NonNull; import javax.validation.constraints.NotNull; import io.micronaut.core.annotation.NonNull; import org.springframework.lang.NonNull; import reactor.util.annotation.NonNull;

Did you try https://github.com/uber/NullAway?

Re: Retrofitting null-safety onto Java at Meta

#185

Post by Retric »

pron wrote: post #155
Retric wrote: post #137

Earlier quoted context omitted.

I know vastly more programmers that have abandoned Java than swapped to it. That’s not to say it failed. Java is one of the most popular languages, but it does suggest real issues with the current approach.

And you could probably say the same for JavaScript and Python, that, together with Java, make up the current topmost tier of super-popular programming languages, which is why I think your conclusion is wrong. These three languages are often first languages (or, at least, first professional languages), which is a necessary (though insufficient) condition for being super-popular. All of these languages more than make u…

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

Re: Retrofitting null-safety onto Java at Meta

#186

Post by Retric »

eternalban wrote: post #142
Retric wrote: post #137

Earlier quoted context omitted.

I know vastly more programmers that have abandoned Java than swapped to it. That’s not to say it failed. Java is one of the most popular languages, but it does suggest real issues with the current approach.

I think you are jumping to your desired conclusion here. Even if we take your vastly at face value, there are so many reasons people switch languages, and problematic language evolution is not the only possible reason.

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 resulting in Python’s rise.

Much of this could be fixed with a better tooling and an overhauled standard library, but basic language pitfalls are still a problem.

Re: Retrofitting null-safety onto Java at Meta

#187

Post by eternalban »

Retric wrote: post #186
eternalban wrote: post #142

Earlier quoted context omitted.

I think you are jumping to your desired conclusion here. Even if we take your vastly at face value, there are so many reasons people switch languages, and problematic language evolution is not the only possible reason.

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 things like JSPs and Spring also definitely played a part in motivating seeking more pleasant pastures. So this I would chalk to impedance mismatch between Java and the browser tech.

Second wave was more about 'language'. FP. DSLs. Rich Hickey! State is not identity! :)

Third wave was, imo, due to a more seismic shift that included more victims than just Java. This was the beginning of the noSQL era, "simplifying", Redis! What a breath of fresh air. Again, not that Redis made people switch languages, but that there was a shift in mindset as to how to build software. Java all of a sudden looked like the RDBMs second cousin.

Then the cloud. JVM startup times. Memory footprint, etc. I stopped following Java's progress after 2008, but sense this was the period when the Java stewards finally were motivated to be more adventurous with new features. But in the meantime, Go ended up being the server side networking champ.

But now, with things like GraalVM, I'm actually excited to switch back to Java as my main lang again.

Concurrent with all this, fads as you mention; amplification of unseasoned voices via blog-sphere that shifted mindshare; and just the basic human need to seek variety.

Re: Retrofitting null-safety onto Java at Meta

#188

Post by hn_throwaway_99 »

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.

> I'm sorry, but I don't think you understand the purpose that "Optional" was intended to serve.

Lol, your response is the equivalent of the old SNL "IT guy" skits: "Silly programmer peasant, you don't even know what a monad is!"

Regardless of what you may think Optional was intended to serve, I have seen its use across large and varied code bases, and it simply does not make the cognitive burden easier for developers.

Again, look at the example given by the GP comment. Of course Optional isn't intended to be used that way. But the fact is, as the compiler doesn't prohibit it, it WILL get used that way, and it doesn't provide strong guarantees about the state of the variable.

Re: Retrofitting null-safety onto Java at Meta

#189

Post by pron »

Retric wrote: post #185
pron wrote: post #155

Earlier quoted context omitted.

And you could probably say the same for JavaScript and Python, that, together with Java, make up the current topmost tier of super-popular programming languages, which is why I think your conclusion is wrong. These three languages are often first languages (or, at least, first professional languages), which is a necessary (though insufficient) condition for being super-popular. All of these languages more than make u…

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 outside that group of three (with the possible exception of TypeScript) seems to be threatening any of them.

So Java isn't as dominant as it was 20 years ago, but no one else is, either. And when you compare Java to current landscape, you see that it's in a very enviable position, and it's as safe a bet today as it ever was.

Re: Retrofitting null-safety onto Java at Meta

#190

Post by fuy »

simplotek wrote: post #156
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.…

> But, most importantly, the fundamental issue is that all classes are optional by default in Java (indeed, that's the problem at hand). Adding an Optional class doesn't really mean you can make any non-nullability assumptions about other classes, especially when using different libraries. Perhaps it's just me, but I don't equate optional with nullable. An optional value is just the designer specifying that you may o…

> Perhaps it's just me, but I don't equate optional with nullable.

But the main usage of Optional and similar types in mainstream languages is exactly that - making the potential nullness (is that a word?) of the value explicit in the type.

Post reply on HN