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

Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

jvm-weekly.com

Post reply on HN
Print view View original

371–380 of 464 posts

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#371

Post by kuhsaft »

WorldMaker wrote: post #354
cogman10 wrote: post #202

Earlier quoted context omitted.

Part of the reason Java hasn't reified generics is because C# did and it was a real big headache that also limited non-C# languages on the C# runtime (CLI?). Everything had to be recompiled to work with newer C# runtimes. While it's pretty easy to run a bunch of language on the JVM (Javascript, python, ruby, clojure) doing the same for C# is somewhat a nightmare, particularly for non-type aware languages. For example…

IronPython did just fine with reified generics.

There's also https://github.com/ikvmnet/ikvm that converts Java bytecode to CIL; essentially Java on CLR.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#372

Post by haspok »

63 wrote: post #305
devin wrote: post #295

After reading a lot of comments in here, there is one thing that always repeats itself in Java/JVM-related comment sections on HN. There are a surprising number of people who have an idea of what the JVM or Java used to be and have very little idea of what it is today. It is a very fit predator in 2026. Does it have its warts? Yes, but the substrate is extremely good.

Many of us work on Java monoliths that started in the 2000s when it was in vogue and we still have to keep them chugging along on Java 8. Personally I'm familiar with all the new features that have come out in the last few years, but for my actual work, java is literally stuck in the past.

In this sense, Java is already the next Cobol. I usually ask one or two questions about class loading in interviews (of senior Java devs), the younger ones are frequently stumbling upon these, and they don't even understand why I'm asking this. Good old Tomcat days, when you could run out of PermGenSpace if you weren't careful :)

Good news is, Oracle extended extended extended support for Java 8 will not last forever, and eventually - if you work in a regulated industry - the company WILL have to pull the trigger.

On the other hand, "where there is muck, there is brass", so a little bit of legacy can be beneficial for some.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#373

Post by Panzerschrek »

> we want the JVM to be able to treat them as efficiently as primitives.

They want basically to solve the main Java design flaw with (almost) everything is a reference paradigm. C++ and Rust have had value-types from day one.

> 64 bits, including the null flag

So, this basically makes every value-object optional, adds extra overhead and makes code less safe to null pointer dereference errors.

> but a class with, say, two int fields or one double may not fit in an atomic write and end up as an ordinary object on the heap anyway

So, the whole optimization is applied only for very small structs with no more than two scalars (or so). Did it worth to spend 10+ years of development to achieve this?

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#374

Post by kuhsaft »

kuhsaft wrote: post #356
jmyeet wrote: post #98

Earlier quoted context omitted.

The type erasure version of this would look a lot like Hack [1]. So generic arguments would simply have a ? if they allow nulls eg List . The list itself couldn't be null unless it was ?List . Now, one can argue that this is just smoke and mirrors with type erasure and it is but you can already put a Date into a List if you're so inclined because the JVM doesn't know the difference, hence type erasure. So this is no…

> Now, one can argue that this is just smoke and mirrors with type erasure and it is but you can already put a Date into a List if you're so inclined because the JVM doesn't know the difference, hence type erasure. And that's a massive problem that they're planing to solve with specialized generics. > If I read the correctly, it means that if you have a Point value class then on the JVM level you'll be able to stuff…

All that to be bytecode backwards compatible, although behaviorally there are some breaking changes. See https://news.ycombinator.com/item?id=48597943

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#375

Post by abbeyj »

recursive-call wrote: post #105
fsuts wrote: post #101

Java = Oracle = Ellisons way of doing business Unless your company forces you to use Java for new projects, consider a change

name another statically typed, compiled, mature language with a bunch of packages for everything and maybe I will /srs

The one that immediately springs to mind is C#. Of all the mainstream languages it is probably the one most similar to Java. It can be compiled into platform-independent bytecode (like Java) or into native code using Native AOT. Relevant to the subject of this article, it has had support for structs (user-defined value types) since C# 1.0 in 2002.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#376

Post by zingar »

I love a long form programming deep dive. I have questions, probably basic ones that belong in undergrad CS but it’s been … a while.

1. Can someone remind me why it was so important/intentional at the start of the language that every object has identity? 2. Why is it important that we not synchronize on these value objects?

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#377

Post by Cthulhu_ »

ericol wrote: post #270
rayiner wrote: post #264

Earlier quoted context omitted.

You see this in all the AI generated Tik Toks. What causes AI to use such a weird construction.

Wait until in 5 year's time all kids speak in rule of 3

Not rule of one. Not of two. But three.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#378

Post by joe_mwangi »

jessinra98 wrote: post #99

The article has a section about that. For me, a struct in C/C# can be modified and is passed by copy while a value class can not be modified and is passed by value. I do not think you can do stack allocation in Java.

Yup. By design, value classes will use cpu registers as a 1st priority instead.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#380

Post by gf000 »

tsimionescu wrote: post #190
gf000 wrote: post #180

Earlier quoted context omitted.

Mistyped, it's sealed interface. > So you can always have `Maybe x = null`, or even `Some x = null`. Yeah and? Practically every type system have escape hatches, like Haskell can also do side effects without the IO monad, does it make the latter useless?

The whole point of using Optional/Maybe is to prevent the possibility of accidemtally creating nulls. If you don't make mistakes, then nullability is not a problem. If you do make mistakes, then a class that only helps when you don't make mistakes is basically useless. This also has significant impact for serialization/de serialization - a classic place where you get unexpected nulls, that Java Optional/Maybe don't h…

Disagree.

Types are both for the compiler, as well as for the developer. Maybe types are implicit documentation telling the developer that it is meaningful in the application that this field can have a None state.

That's a huge code smell to ever set null to an Optional/Maybe and code reviews, linters, nullness analyzers all should/will flag such.

Like I have never ever had an NPE from an Optional being null. Sure, complete null safety would be better of course, but in this very instance it ain't buying you much.

Post reply on HN