Loom is rather nice, but frankly I don't find the lack of co-routines something I miss. You can spawn hundreds of real threads a second so it is possible to write Go style code in Java if you really want. I may change my mind when I actually use it though.

I don't mind what type of data classes they come up with. I just want to not have to write stupidly long constructors, multiple sets or chain-able objects when I want to populate some fields.

I've definitely had to fix servers that have choked themselves with thread abuse, so maybe it's ptsd. The fixes can be as simple as shrinking threadpools to needing substantial rewrites, so I still treat threads as resources requiring management.

Green threads are nice because they let me separate logical execution from operating system resources. Unlike Go, Java will expose the ability to use a custom scheduler, so that should be nice!

My personal pet usecase is actually the opposite. I want to isolate 5-10 "low priority" tasks to a single kernel thread to isolate how much damage misbehaving code can do.

You can already use custom schedulers with java.util.concurrent though.

Except that the memory overhead for each thread is MUCH higher: the default would be 1Mb for most JVM implementation.

Yes, you can change the thread stack size, but that's a global fixed size for all threads, so you can't make it to small, or you'll risk stack overflows.

Meanwhile, Go is using dynamically growing stacks, starting at 2k.

It doesn’t actually use 1mb. Only if the stack touches the pages will it ever allocate the physical memory. Most threads won’t use more than 16kB (the lower bound when I last tested it on x64). Still, it’s a lot larger than green threads.

Java already has both records/data classes[1] (including pattern matching) as well as value classes[2] in the works.

[1] https://cr.openjdk.java.net/~briangoetz/amber/datum.html

[2] https://openjdk.java.net/projects/valhalla/