Library for fast mapping of Java records to native memory • Hacker News Board

Re: Library for fast mapping of Java records to native memory

#41

Post by wood_spirit » Tue, May 12, 2026, 1:03 PM UTC

whizzter wrote: post #36

joe_mwangi wrote: post #34

Earlier quoted context omitted.

It's a long roadmap, but this is their ultimate objective. Once java has value classes, future carrier classes and member patterns, that's when we shall see some very huge interest for java in ML. Also, they plan to introduce typeclasses in which it will be convenient to introduce operator overloading, and collection/array literals etc syntax. The idea is to unify the types in java, and then enable much stronger sema…

Valuetypes has been on the roadmap forever, meanwhile they put in the effort and bought out greenthreads out of retirement as virtual threads. Even if they started properly on valuetypes today, it's probably still a 10 year slog to get the ecosystem to follow.

FWIW virtual threads are great this time around. That’s something whose time has come generally.

But yeah for me Java took a big leap forward when it got lambda but there hasn’t been another big leap since. Still so many obvious features and sugar to add to file off the sharp edges and remnants of enterpriseness.

Re: Library for fast mapping of Java records to native memory

#42

Post by traderj0e » Tue, May 12, 2026, 4:39 PM UTC

saagarjha wrote: post #31

traderj0e wrote: post #22

Earlier quoted context omitted.

I'm glad they saw the light. Last time I used Java was in high school when it was version 7, when it was pure OOP. Didn't even have lambdas. After I learned other languages, I didn't want to use Java again, seemed like a lot of boilerplate for something that didn't even give good performance.

Maybe you should check again if the last time you used it was Java 7.

I've looked, it's better now, hence my comment that they saw the light. They got lambdas, records, and auto types. More importantly they got virtual threads, but that's unrelated.

Re: Library for fast mapping of Java records to native memory

#43

Post by whizzter » Wed, May 13, 2026, 12:17 PM UTC

wood_spirit wrote: post #41

whizzter wrote: post #36

Earlier quoted context omitted.

Valuetypes has been on the roadmap forever, meanwhile they put in the effort and bought out greenthreads out of retirement as virtual threads. Even if they started properly on valuetypes today, it's probably still a 10 year slog to get the ecosystem to follow.

FWIW virtual threads are great this time around. That’s something whose time has come generally. But yeah for me Java took a big leap forward when it got lambda but there hasn’t been another big leap since. Still so many obvious features and sugar to add to file off the sharp edges and remnants of enterpriseness.

[dead]

Re: Library for fast mapping of Java records to native memory

#44

Post by fweimer » Thu, May 14, 2026, 2:23 PM UTC

spockz wrote: post #20

fweimer wrote: post #9

Earlier quoted context omitted.

I doubt value classes will be helpful here because the array would have to be immutable. Context: https://openjdk.org/jeps/401

Why does the array need to be immutable? Isn’t it enough to allocate the pessimistic max size of the record times the size of the array? In go slices work quite nicely to deal with “immutable” arrays and still be able to work on views on those arrays while keeping the same memory backing.

As kbolino said, value objects are immutable. If you can get a reference to a value object in an array, the array has to be immutable.

If you cannot get a reference, it's possible to maintain mutability, but all access would involve copies. But it's not clear that this is what most people want because it's rather similar to what you can do with library-based solutions today (involving ByteBuffers and whatnot).