概述
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也可以靠生态和其他语言持续下去。
最后
以上就是整齐小白菜为你收集整理的Java是有多垃圾你能想象得到吗?的全部内容,希望文章能够帮你解决Java是有多垃圾你能想象得到吗?所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复