The same thing goes for value types. In Go, everything uses value types. The standard library is littered with them. Will it be the same for Java? It seems unlikely, given that they have to keep backwards compatibility.
Granted, this is all from the point of view of an outsider who only dabbled in Java, so I may be way off base.
And there were alternatives available before for Java 1.4.
Which means most Java libraries had lots of time to adapt to it.
Also threads and concurrent queues are there since the early days.
Java already has a kind of pseudo-value types, but it is JVM specific. Some JIT and AOT compilers do convert final classes with only accessors (think Point) to value types.
But yeah, it is a JDK vendor specific optimization that one cannot control.
Likewise you cannot control if a value type in Go gets stack or heap allocated, if I remember correctly. Hence why the compiler options to debug how the compiler decided to do it.
Java value types will take time to get adopted surely, but in many type of applications it doesn't really matter that much.
The use cases driving value type's adoption are related to HPC and HPT, many of which are trying to move away from C++ into Java, but still find themselves have to make use of com.sun.unsafe for that last mile.
At least as presented by IBM and Azul on their talks about their approaches to value types in Java.
Also Go's advantage in using value types will vanish when Java finally gets to have them, although we still need to wait for Java 10 for them, while Go is available now. So Go does have a few more years to gain developer mindshare.
Still Java isn't the only game in town, and there are other alternatives with GC, value types, more expressive type systems and battle tested concurrency frameworks.
How the mighty have fallen. A language with more than decade over Go and billions in investment by top tech companies and literal monopoly over enterprise usage need to even think of user share of a marginal language.
What is driving value types in Java is HPC and HPT companies in places like stock exchanges and biology research that want to move away from C++ into JVM land, but still need to keep some C++ around due to value types or make use of com.sun.unsafe tricks.
Nothing to do with Go.
The only thing Go concurrency has over them is that it is easier to start with, but it isn't easier to use any other pattern, because Go doesn't allow library code to be first class in the type system.