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

341–350 of 464 posts

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

#341

Post by layer8 »

inigyou wrote: post #61
layer8 wrote: post #30

Earlier quoted context omitted.

There’s nothing wrong with having non-normalized representations, that’s why there is equals(). For example, you might have a value class for representing (limited-precision) fractions using two long s internally, for the numerator and denominator. For efficiency trade-off reasons, you don’t want to always shorten the fraction. But now client code can distinguish 2/3 from 4/6 using ==. Scenarios of that sort are conc…

Java can also distinguish a 2/3 object from a 4/6 object using == when they are not value types. It can even distinguish a 2/3 object from a different 2/3 object.

The difference, as I tried to explain, is that identity comparison does not expose the internal representation. So while you can know that two objects with the same value are different objects, you can't know whether they internally represent the value as 2/3 or 4/6. With value classes, however, the latter can expose information about the provenance of a value.

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

#342

Post by lotyrin »

vips7L wrote: post #313
63 wrote: post #305

Earlier quoted context omitted.

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.

Any reason why? My entire company is on 21-25. Except for one project that decided to use sun.internal.* classes.

Paying back tech debt, being able to keep up with treadmills (even slow and smooth ones) is depressingly rare.

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

#343

Post by edumaxsantos »

petilon wrote: post #323

I understand the rationale for value classes, but the implementation is flawed. What will this code print: Point a = new Point(10, 10); Point b = a; a.x = 100; System.out.println(b.x); Until now the answer was obvious. Now with the addition of value classes, the answer depends on whether Point is a value class or a reference class. So readability suffers with this design. This is a violation of the principle of unifo…

based on the goals from JEP 401 [1], this is not possible, as value classes are meant to "Allow developers to opt in to a programming model for immutable data(...)"

[1]: https://openjdk.org/jeps/401

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

#344

Post by pron »

Athari wrote: post #280
revetkn wrote: post #229

Earlier quoted context omitted.

Regarding "What's wrong with what .NET did with threads?", see https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html (relevant part below): An alternative solution to that of fibers to concurrency's simplicity vs. performance issue is known as async/await, and has been adopted by C# and Node.js, and will likely be adopted by standard JavaScript. Continuations and fibers dominate async/await in the sense that asyn…

The colorless functions approach has well-known disadvantages though, including providing less control and making interop a pain. It isn't like one approach is the correct one and another is a mistake.

> including providing less control and making interop a pain

This is true in some languages but not in Java. The limitations (and performance cost) are not from the nature of continuations/stackful coroutines/"colourless functions", but from their interaction with other constraints and existing designs in the language. E.g. in Java, virtual threads have zero impact on FFI.

In general, the costs and limitations associated with a feature in language X don't extrapolate to language Y, because they often stem from interaction with existing constraints in language X.

The design of FFI is a very common source of problems for various features. For example, if the FFI is designed such that you frequently pass pointers to to objects to C, that can have a big impact on other features. In Java, you nearly always only pass pointers to "off heap" memory, i.e. memory that's not managed directly by the JVM. While this has no performance cost, you could say that this, in itself, has some convenience cost, except Java programs need to rely on FFI much less than other languages, so the overall cost to convenience is low.

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

#345

Post by crummy »

layer8 wrote: post #341
inigyou wrote: post #61

Earlier quoted context omitted.

Java can also distinguish a 2/3 object from a 4/6 object using == when they are not value types. It can even distinguish a 2/3 object from a different 2/3 object.

The difference, as I tried to explain, is that identity comparison does not expose the internal representation. So while you can know that two objects with the same value are different objects, you can't know whether they internally represent the value as 2/3 or 4/6. With value classes, however, the latter can expose information about the provenance of a value.

Would you use a value class if you wanted to represent a fraction?

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

#346

Post by Exoristos »

rayiner wrote: post #275
wongarsu wrote: post #274

Earlier quoted context omitted.

I learned that exact style of writing in a marketing workshop, pre-AI. It's effective, satisfying, and a random third thing I can't be bothered to come up with right now. As a proportion of all easily crawled text on the internet, a lot of it will be random marketing copy. That influenced the writing style of early AIs, and since then everyone has trained at least partially on transcripts from every other AI chatbot

Oh my god did we inadvertently train AIs on idiotspeak.

There was nothing inadvertent about it. A decade of cultivating and harvesting millions of examples of this kind of pseudo-writing from underpaid internet piece-workers preceded LLMs.

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

#348

Post by kllrnohj »

jmyeet wrote: post #92
rf15 wrote: post #4

I appreciate the hard work that went into the things that did make it into Valhalla eventually, but: > The model was powerful, but also mentally heavy No it isn't! it is this interpretation that kills off the null-safety debate entirely. Saying you have a variable that cannot be null is not a mentally taxing distinction, especially since everything is labelled thoroughly. > The team, faithful to the lesson “simplify…

Java made several mistakes. It also made some questionable (yet often defensible) decisions. It's understandable. Type erasure was one I believe was a mistake. It's talked about in the article. Yes, you kept binary compatibility but you that created so many other problems such as not being able to use value types in generics. Notably, C# looked at that and said "nope". Type erasure is also hurting Valhalla here and t…

> Yes, you kept binary compatibility but you that created so many other problems such as not being able to use value types in generics.

This is often given as the defensible reason, but it's not even that true. Java 1.5/5 had several "breaking" changes in it regardless including the newly reserved 'enum' and a whole freaking memory model update.

And besides if any of your dependencies updated for all practical purposes you did, too, since you had to use a newer runtime to run their code regardless, it never really made sense to keep using an older javac out of spite

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

#349

Post by lowbloodsugar »

boroboro4 wrote: post #320
lowbloodsugar wrote: post #230

Earlier quoted context omitted.

Which is why this is the wrong approach. Again. This is a major misstep.

The core insight there is to separate value semantics (no identity) from reference (itself) semantics (nullability). While this particular change can bring very limited amount of improvements it’s still does some - probably smaller to no object header + more guaranteed optimizations for variables on stack. It’s when they land next part (nullability) it will shine fully - particularly on the intersection of not null a…

It seems to me that the "and a null flag" is adding a tremendous amount of unneeded complexity. Supporting null seems to be about avoiding C#'s ref/in/out solution. I suppose that, from a JDK dev's perspective, that's a reasonable requirement. I just hope that we actually get non-null.

I'm not sure the no-tearing rule is particular helpful either. Like, this is something folks get wrong all the time in regular java. There's plenty of places where we use unsynchronized classes and expect synchronization to occur in the containing class or other explicit lock. If atomic operations are a requirement, and non-atomic value types get turned into references, then value types seem pointless.

I fear we're getting something called "Value types" with none of the actual benefits of value types. Like "we heard you want something called value types so here you are". No, we wanted a way to declare arrays of structured values without having to deref pointers, or to store structures inline as a field within an object. What I've read seems to be not that unless the structure's total size is 63 bits...

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

#350

Post by wbl »

bradleyjg wrote: post #338
pron wrote: post #272

Earlier quoted context omitted.

What's funny is that the only languages in the same popularity league as Java are Python and JS/TS (and possibly C and C++ if you want to extend things to more domains) yet I rarely ever hear people saying Java should be more like these languages. It's because many of the people who dislike Java also don't like any of the most popular languages (even those who like, say, Python better don't think Java should be more…

I definitely see people asking for features from c++. In part because virtually every feature is in c++.

That tends to be a reason to say no- remember the vasa!
Post reply on HN