joe_mwangi

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.

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

Hahaha... inspired by it actually.

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

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

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

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.

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

Typeclasses are coming. And they will use them for growing the language such as operator overloading, collection literals, narrowing & widening types, etc.

This article doesn't talk about Valhalla and doesn't talk about java pattern matching in depth. It should have been titled as Kotlin vs Rust.

I shifted to java modules. It solved many things especially using jpackage. Latest java version handles import hell reducing import clutter.

It was submitted recently 2 weeks ago hence we might see something in future releases too.

Type class approach seems quite a novel strategy. Using monoids, groups, rings, etc for algebraic structures in type class (interface), one can model operator overloading, collection literals, type conversions. Seems people in Haskell have been enjoying a lot.