I'm not sure what is meant here by "on par with the JVM." I'm not trying to claim that one or the other is better, but there is a basic difference in how they're designed and continue to evolve. .NET believes in a language that gives more control on top of a more basic runtime, while Java believes in a language that's smaller built on top of a more advanced runtime. They just make different tradeoffs. .NET doesn't "need" a more advanced runtime because limitations in its runtime can be overcome by more explicit control in the language; Java doesn't "need" a more elaborate language because limitations in the level of control offered by the language can be overcome by a more sophisticated runtime.
I'm not saying these are huge differences, but they're real. C# has more features than the Java language, while Java's compiler and GCs are more sophisticated than the CLR's. Both of these differences are due to conscious choices made by both teams, and they each have their pros and cons. I think these differences are very apparent in how these two platforms tackled high-scale concurrency: .NET did it in the language; Java did it in the runtime. When it comes to value types, we see a similar difference: in C# you have classes and structs (with autoboxing); in Java we'll just have classes that declare whether they care about identity, and the runtime will then choose how to represent each instance in memory (earlier designs did explore "structs with autoboxing" but things have moved on from there, to the point of redefining autoboxing even for Java primitives; for a type that doesn't care about identity, autoboxing becomes an implementation detail - transparently made by the compiler - with no semantic difference, as a pointer or a value cannot be distinguidhed in such a case - hence https://openjdk.org/jeps/390 - unlike before, when an Integer instance could be distinguished from an int).