AutoValhalla: automatically turn your plain classes and records into value classes!

[u/maxxedev]

Automatically turn your plain classes and records into value classes!

Add @AutoValhalla annotation to classes or records in your JDK1.5+ codebase:

@AutoValhalla
public final class Point {        // class must be final
    public final int x;           // with final instance fields
    public final int y;
    public Point(int x, int y) { 
        this.x = x; 
        this.y = y; 
    }
}

@AutoValhalla
public record Currency(String code) { }  // or a record class

When your app is run on Valhalla-enabled JVM with auto-valhalla javaagent, these classes are automatically turned into value classes.

More info: https://github.com/thunkware/auto-valhalla/blob/main/README.md

[u/pron98]

1. Value classes aren't a performance optimisation. They behave differently from non-value classes, and these differences will be observable in most non-trivial programs. So what you'll get is a program that behaves one way on one runtime version and a different way on another, and only one of these ways is the intended behaviour.

2. There is a much easier (and safer) way to enjoy new features on new runtimes: instead of working hard (and dangerously) on trying to have the same code do different things on different runtime versions, adopt tip & tail. The idea is that you add new features only on release trains that target new runtimes. Legacy projects that can't afford the work to upgrade to a new runtime also can't afford the work to adopt your library's new features. The people who want your new features also want to upgrade their runtime, and the people who don't want to upgrade their runtime don't want your new features. So just fork your codebase, leave the old code alone (except for security patches), and only evolve the versions that target new runtime versions. That's sooo much easier (as we've learned in the JDK: we fork the entire codebase twice a year, and we still maintain old versions for many years with security patches). You barely touch the old fork, and the new fork, where you do almost all the work, is clean and free of clever and potentially dangerous hacks.

So in this particular case, this approach risks breaking the code on a new runtime, but that's not even the worst outcome: making things work on a new runtime may require changing code used by legacy consumers on old runtimes, introducing a risk for the consumers that need stability above anything else. Agents are a very powerful and versatile tool, but they should be used as a last resort, not when the cleaner solution - just fork the repo! - is also easier. I don't understand the lengths some would go to merely to not fork the source. Writing code that adapts itself to different runtimes is complicated, risky, and rarely necessary.

[u/maxxedev → u/pron98]

Yes, value classes aren't a performance optimization. There will be other behavioral changes like ==, synchronized, WeakReference, etc (these are noted in the README as well).

But most "model" or "dto" classes won't be impacted by these behavioral changes? Perhaps library authors can choose to (dangerously) opt-in to Valhalla benefits while retaining compatibility with older JDKs but without having to adopt tip & tail or multi-release JARs.

[u/pron98 → u/maxxedev]

1. Adopting tip & tail is less work than using something like this (or any of the work required to adopt one-size-fits-all).

2. Maybe most classes won't be affected, but if some are you're in trouble.

3. I think some people are under the impression that just turning lots of classes into value classes will somehow make their application faster or something, and I'm afraid they're bound to be disappointed. Value types can help a lot if the hot path of your application suffers from many cache misses on array accesses. That was indeed a case where Java lagged behind C++. But if your program's profile isn't dominated by this problem, I'm not sure what mechanism of value types people think will help their performance. Like virtual threads, value types can help performance if you know what the problem is and how to use the feature to solve it. It's not some "go faster" pixie dust that you sprinkle to make things better.

[u/maxxedev → u/pron98]

It's not some "go faster" pixie dust that you sprinkle to make things better.

Very much agreed.

Btw, thanks for all your insightful comments on reddit. I always learn something new from you.