JVM非常优秀，gc效率很高了

- 但是从VM来说比.net还差了一点。

- 比如不支持互相递归的尾递归优化和真泛型。

当然这是历史遗留问题，Java一开始没有泛型，后来像Go一样遇到了各种不便，所以Java 1.5还是1.6（忘了）加了，为了考虑兼容性，JVM本质上是没有泛型的，现在的泛型靠的是运行时强转。

比如在JVM上的语言Scala在pattern matching的时候写case x：Vector[Int]会匹配到所有Vector。但是Java的语法一言难尽，interface不够强，只能搞Spring这种框架搞依赖注入。

没有语言级别的委托和属性，所以要写getter与setter，不能像C#一样写public string Name { get ; set };，泛型没有协变逆变，只能写public List<? extends U> map(Function<? super T , ? extends U> f)这种东西。

而且没有Algebra Data Type，处理Option，Tree这种数据类型很麻烦。同时不支持path-dependent type，要写x.new xs()来实例化内部类。

Java的面向对象设计不好，基于类又有static这种不纯面向对象的东西。

要这样搞不学Simula和SmallTalk一样搞pure-OO。

而static有有不少局限，所以出现了单例模式。

看看隔壁Scala的object设计（可以在object里重写super class的方法），就知道Java的对象系统有多么糟糕。

同时Java不支持操作符重载，所以BigInt/BigDecimal 与原生数字类型还差了那么一点点。

比如x.plus(BigInteger.ZERO)，Scala可以写x + 0。

而且Java把基本类型（int short byte double这些）和引用类型（用class定义的）分开了算，而且泛型不能那基本类型做参数。而Scala是没区别的，JVM上用原生类型实现。

所以Scala里有Vector[Int]，Java要用包装类型Integer。

而且Java的==对于基本类型检测是否相同，对于引用类型来说是检测地址相同。

所以就算obj1和obj2相同，obj1 == obj2可能交出false。

这就导致了Java对象判断相等要用obj.equals(x)。Scala只要obj1 == obj2。

要判断引用相等性就obj1 eq obj2。

Java在设计上讲究抽象，然后抽象能力有不过。

Interface没有解决多继承问题，还有很多限制。

而Scala用线性化很好的解决了这个问题。

有没有ad-hoc多态与type class，也没有implicit，所以语言的抽象能力不够。

比如Stream和IntStream，就是因为没有Numeric[T]（Scala）这种type class。

所以要单独搞数字类型的Stream，里面定义了sum。而Scala的sum是def sum(implicit ev:Numeric[T] ) = this.foldLeft(ev.zero)(ev.plus)。

而且Java的类型系统也不够好，不支持HKT，所以没有trait Monad [M[_]]这种东西。

所以Java的抽象能力不够，连实现type class的最后希望也没了。

Java的生态和社区不错。这个你可以自己体验。

但是Java 8的Stream和Scala比差了不少，没有reduceLeft/Right和foldLeft/Right。

Java不会消亡，只会改进，最后可能会变成C#++ on JVM的样子。

JDK 14的switch expression和record改变了不少问题。让语言更强大JVM也不会消亡，有Kotlin和Scala撑着，就算Java在垃圾JVM也可以靠生态和其他语言持续下去。