Hacker News: joe_mwangi

New comment by joe_mwangi in "First Valhalla related stuff will land in Java 28"

joe_mwangi — Wed, 10 Jun 2026 18:50:35 +0000

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

New comment by joe_mwangi in "Where Is the JVM Tax?"

joe_mwangi — Mon, 25 May 2026 16:21:10 +0000

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

New comment by joe_mwangi in ".NET (OK, C#) finally gets union types"

joe_mwangi — Sun, 24 May 2026 20:03:45 +0000

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.

New comment by joe_mwangi in ".NET (OK, C#) finally gets union types"

joe_mwangi — Sun, 24 May 2026 19:58:30 +0000

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.

New comment by joe_mwangi in ".NET (OK, C#) finally gets union types"

joe_mwangi — Sun, 24 May 2026 07:49:01 +0000

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#.

New comment by joe_mwangi in "Java: Rethink Domain Primitives with Valhalla"

joe_mwangi — Wed, 20 May 2026 14:12:31 +0000

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.

New comment by joe_mwangi in "Library for fast mapping of Java records to native memory"

joe_mwangi — Tue, 12 May 2026 12:28:00 +0000

Great stuff!!!

New comment by joe_mwangi in "Library for fast mapping of Java records to native memory"

joe_mwangi — Tue, 12 May 2026 08:30:39 +0000

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

New comment by joe_mwangi in "Library for fast mapping of Java records to native memory"

joe_mwangi — Tue, 12 May 2026 08:27:20 +0000

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) {}`

New comment by joe_mwangi in "Library for fast mapping of Java records to native memory"

joe_mwangi — Tue, 12 May 2026 07:12:38 +0000

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.

New comment by joe_mwangi in "Library for fast mapping of Java records to native memory"

joe_mwangi — Mon, 11 May 2026 21:39:05 +0000

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.

New comment by joe_mwangi in "Library for fast mapping of Java records to native memory"

joe_mwangi — Mon, 11 May 2026 21:18:20 +0000

Interesting approach. I think Project Babylon did the same thing https://github.com/openjdk/babylon/blob/code-reflection/hat/...

I had tested it and it's quite fast. Actually, you don't need to generate any bytecode on the fly. Problem is when you deal with array as fields, implementation becomes difficult. You can revisit if interested to come back to such an implementation one day.

New comment by joe_mwangi in "Library for fast mapping of Java records to native memory"

joe_mwangi — Mon, 11 May 2026 21:02:48 +0000

Hope you come back. Would be cool to venture in this new data oriented programming phase java has invested a lot in.

New comment by joe_mwangi in "Library for fast mapping of Java records to native memory"

joe_mwangi — Mon, 11 May 2026 21:01:45 +0000

Hahaha... inspired by it actually.

New comment by joe_mwangi in "Library for fast mapping of Java records to native memory"

joe_mwangi — Mon, 11 May 2026 21:01:21 +0000

Yeaaah. You might be right. Hopefully we have this one day https://openjdk.org/jeps/8261007

New comment by joe_mwangi in "Library for fast mapping of Java records to native memory"

joe_mwangi — Mon, 11 May 2026 20:56:55 +0000

I use c-struct layout. I should be more explicit in the readme. I use classfile api to generate bytecode during initialisation of the Mem and bytecode stored in cache in case if initialised again somewhere based on the same record type (I don't cache for records that are declared locally in a method). The class created from implementing Mem is a hidden class. So, basically, given a record, one can be able to analyse the layout based on record state description, and then for that Mem implementation (hidden class) we generate static final field varhandles + layout, segment is an instance field, and then generate bytecode the get and set to avoid reflection (actually, this is where most headache is in implementation). Go to the test package and see simple code for some adhoc rudimentary java (and native) files for benchmarks. Planning to test JMH benchmarks soon.

New comment by joe_mwangi in "Library for fast mapping of Java records to native memory"

joe_mwangi — Mon, 11 May 2026 20:10:56 +0000

Thanks. Main goal. Unions is where I decided to pause - no simple and ergonomic way to do it at the moment.

New comment by joe_mwangi in "Library for fast mapping of Java records to native memory"

joe_mwangi — Mon, 11 May 2026 20:07:34 +0000

Yup. Totally agree. Java does needs an array of structs. Hopefully value classes will help out through flattened array. But in future, one can use value records with this library with probable zero cost allocation. But the library doesn't use any reflection calls for get and set hence high performance as a result, and using records helps a lot with escape analysis. Planning to do some serious benchmarks soon. Some preliminary tests shows it's similar to c code (example code in test package). Performance suffers if record fields are arrays due to heap allocation of arrays.

Library for fast mapping of Java records to native memory

joe_mwangi — Mon, 11 May 2026 19:33:31 +0000

Article URL: https://github.com/mamba-studio/TypedMemory

Comments URL: https://news.ycombinator.com/item?id=48099616

Points: 166

# Comments: 37

New comment by joe_mwangi in "Java 26 is here"

joe_mwangi — Sat, 28 Mar 2026 10:54:36 +0000

Here it is https://youtu.be/Gz7Or9C0TpM?si=Rk5pTeAC6ibqS-M-