joe_mwangi

Trust me. That's a common argument used when java introduces new features. Wait you see the same argument once value classes come to jdk 28.

Yes.. lol. The biggest argument now is Kotlin having nullness by default in the language. Just check around the comment section. Now java is planning to have them which will further help jvm to optimise for performance. Not sure what the next argument will be after.

Really? I don't thinks so. There is a reason JEP 539 is in preview. There is a reason internal annotations exists in current valhalla jdk prototype and upcoming java 28 such as @jdk.internal.vm.annotation.NullRestricted, @jdk.internal.value.ValueClass.newNullRestrictedNonAtomicArray. Also, there is a reason value classes are allowed to be null. This is because nullness types will be a key factor to the java language.

Once it gets nullness types, hackernews is gonna explode!

Typeclasses caught me by surprise. Smart move by the java team.

Also, future specialisation if it is introduced, it will enable the JIT to get enough information to ensure <T> becomes stored in cpu registeres or enable <T[]> to be flattened in memory.

Yeaaah. They are going to introduce approaches for the programmer to decide if tearability is allowed or not. Already there are internal annotations for fields and types to enable it that probably will become a language feature in future.

They are researching to have immutable arrays. Also multifields (stack allocated arrays as fields in value classes). So, there is a possibility.

I've done some tests with current value classes in latest prototype with full optimisation through annotation. Apparently, everything was being compiled to assembly code with no gc calls. It seems this old school ideology of slow java is about to end in near future. I'm actually intrigued how it will compete with Rust which can't optimise code further while running, while JVM JIT has more info which it could aggressively further optimise, especially hot paths.

Also, this will be used for future null-restricted types.

Better late than never.

This time, 30mb.

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

Until they implement member patterns. https://openjdk.org/projects/amber/design-notes/patterns/tow...

> yet But up the comment section, someone thinks they won't be there 'in the future'

And I notice, people aren't aware more things are being planned for. For example, the carrier classes being proposed, they will separate state description with state representation and this is where value classes will shine syntactically.

And the only syntax change is adding 'value'.

Since they plan to have null-restricted types, then I don't see any issue.

But with null-restricted types, Integer! and int has no difference semantically and representation. They plan to introduce null-restricted types in future.

This is awesome. First step to an interesting direction of the language.

More reasons why java value classes will be a game changer.

Java’s planned approach is more like typeclass-style interfaces than unrestricted operator overloading. Types opt into core-defined operator contracts, rather than every library inventing arbitrary meanings for symbols.

Damn. You're old school. Java’s answer is virtual threads, not async/await. The idea is that most server-side IO can stay in direct style enabling blocking-looking code, cheap virtual threads underneath. So you don’t split the whole codebase into sync vs async functions just to avoid blocking OS threads. CompletableFuture and reactive APIs still exist, but Loom reduces the need to use them as the default application model. You can now launch millions of virtual threads to do IO.

Notice you point out features that were easy to add during the beginning where there was no concern of backward compatibility? Now that java is porting value classes to mainline and we might have them soon, and planned operator overloading through type class, I believe java approach is making careful design choices that are semantically sound, rather than adding features that create edge cases such as boxing invariants in unions like C#.

Value types will be optionally null. What java will introduce to the tooling is narrowing of nullness types. Hence Foo! <: Foo? <: Foo. This will assist in enabling safe domains or scope in code that are null-restricted with ease. Hence we can model around such a type system rule.

Great stuff!!!

Yup. They started transferring to the main line, but will require many tests to know if they have any issues. https://github.com/openjdk/jdk/pull/31120

I'm actually planning to resurrect a dead raytracer project (https://github.com/mambastudio/MambaTracer) that has a GPU backend. And possible develop a future 2D API (a lot of work I know). There is an interesting world in multipurpose programming of GPUs, and it took me a while to realise prefix sum is the “hello world” in that area. As a matter of fact, most GPU code without efficient GPU prefix sum, don’t perform well for specific algorithms that might require some scan data, and that’s where CUDA dominates, which has an amazing implementation, and not in other areas such as OpenCL. The raytracer I was making, I encountered a bug that took me I think a month to deduce after some frustration, based on a discovery of my rudimentary struct implementation (through classes and annotation – which I totally agree with you they are a bit annoying) had an misalignment layout which made me rethink, something is wrong with my model approach. So, I needed to solve data and layout representation between java and native code, to be simple, concise, with little headache. If you notice the TypedMemory, the idea is to ensure a user can implement their own libraries with data models without depending on it, and thus becomes a simple plug. Unfortunately, @size will make your code have it as a dependency. Hopefully one day we have multifields as stack allocated arrays (https://web.archive.org/web/20251101203905/https://cr.openjd...) , hence maybe have value `record(char c, float[3] array) {}`

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 semantics to ensure data oriented programming becomes ergonomic in java.

I have not used SBE but looking at it, my understanding is that it starts from an explicit schema, typically XML, and generates encoder/decoder flyweights over a binary buffer. That gives much more control to the user in terms of field order (very important), sizes. Here, TypedMemory takes a different starting point in which the Java record shape is the schema, and the library derives the FFM MemoryLayout/accessors from that. I think the difference is schema/codegen/protocol orientation vs Java-type/FFM/in memorylayout orientation.