Live data from Hacker News

Viewing profile — joe_mwangi

joe_mwangi

HN member
Joined
Wed, Aug 13, 2025, 5:22 PM UTC
HN karma
94
Public activity
43 items

About joe_mwangi

No profile information was provided.

Recent public activity

  1. comment
    Comment #49122164

    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 …

  2. comment
    Comment #49121662

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

  3. comment
    Comment #48807094

    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…

  4. comment
    Comment #48767325

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

  5. comment
    Comment #48684236

    Better late than never.

  6. comment
    Comment #48607544

    This time, 30mb.

  7. comment
    Comment #48607540

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

  8. comment
    Comment #48603253

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

  9. comment
    Comment #48603233

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

  10. comment
    Comment #48600488

    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…

  11. comment
    Comment #48600264

    And the only syntax change is adding 'value'.

  12. comment
    Comment #48600155

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

  13. comment
    Comment #48600142

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

  14. comment
    Comment #48480930

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

  15. comment
    Comment #48268621

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

  16. comment
    Comment #48260546

    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 in…

  17. comment
    Comment #48260507

    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 virt…

  18. comment
    Comment #48255365

    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 an…

  19. comment
    Comment #48208159

    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…

  20. comment
    Comment #48107280

    Great stuff!!!

  21. comment
    Comment #48105682

    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

  22. comment
    Comment #48105660

    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 wo…

  23. comment
    Comment #48105202

    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…

  24. comment
    Comment #48101012

    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. Tha…

  25. comment
    Comment #48100814

    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 …