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