HAHAHAHAHAHAHAHAHAHA. No.
The Java specification allows for green threads, N:1 mapping of threads, or system threads, 1:1 mapping to system threads.
It is up to the Java VM or compiler to offer one implementation or even both.
Tasks in java.util.concurrent make use of thread pooling to also achieve N:1 mapping of tasks to threads.
The Squawk and the Cacao VMs are two examples of a Java VM using green threads,
From the documentation:
"Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run".
Same thing as in Java, just integrated into the language instead of a library. But then again, Scala offers that too.
You had the same thing in early Java with green-treads -- it is abandoned for modern JVMs, but you can mimic it. You can have millions of Scala actors.
>Goroutines are cheap: each goroutine starts at a size of 4k, and creating them is a really cheap operation.
Yes, but handling and migrating them is a "not really cheap operation". They are mostly useful as abstractions, as for performance you don't get anything over Java (if not worse: checkout Go vs Java concurrency benchmarks).
>Please show me a Java thread implementation with the same properties. Good luck with that.
Not sure I need all that "luck" you wish me. How about Java on Solaris, which multiplexes java threads to native threads?
Channels and Goroutines are easily available in java.util.concurrent.
If you really want compilation to pure native code, there native code compilers for Java as well.