Java 与 .NET 的平台发展之争

jopen 11年前

        英文原文:Java faces tough climb to catch up to .Net

        Java 8 即将正式发布,从早期版本中,我们已经可以领略到一些令人兴奋的特性。但是开发者 Andrew C. Oliver 表示,尽管如此,Java 语言在某些特性上还是落后于 .Net。比如,Java 8 中最令人期待的 Lambda 表达式,在 2007 年发布的 .Net 3.5 中已经存在了。他认为,.Net 已有的和即将到来的特性要比 Java 8 优秀得多,如果 Java 9 再不做一些大的改进,那么 Java 落后于 .Net 就不止一点点了。

        关于更新速率

        微软有能力做出更快的改进。我记得在很早期的时候,微软能做到每周都更新数据库 API:从 ODBC、RDO、ADO 到 OLEDB 等。自从出现了 .Net 之后,微软便达到了一种前所未有的更新速度。

        但是 Java 为什么落后这么远?在早期的时候,Java 的发展也是非常快速的,从 Java 1.0.2 到 Java 1.1,仅仅一年时间,我们就看到了 Java 彻底地改变。从 Java 1.1 到 Java 1.2 只用了一年半时间,而 Java 1.2.2 只用了 7 个月的时间(这是一个重要的版本,只是使用了一个小版本号)。而在 10 个月之后,具有关键意义的 Java 1.3 问世,这也正是 Java 发行的第一个带有垃圾回收的版本。

        Java 1.4 为我们带来了 NIO 和正则表达式,但在之后不到两年的时间里就被取消了。Java 1.4.2 版本带来了用于多核环境的垃圾回收器。Java 1.5 带来了可用于生产环境的并行和并发 GC(垃圾回收)特性,它还添加了更重要的并发和 NIO 功能,不过这一过程花了一年多的时间。

        总的来说,Java 还是有不错的表现的,Java 6 使锁变得更廉价,但其在本质上和 Java 1.5 是一样的,还是让用户多等了 2 年时间。Java 7 是第一个对底层 VM 技术做出重大改变的版本,同时还给用户带来了 invokedynamic 特性——用于在 JVM 上更好地连接其它语言,但是在两个大版本的更新之间用了大概 5 年时间,这个进度着实有些太慢了。

Java 与 .NET 的平台发展之争

        为什么 Java 进展缓慢?

        对于这个问题有一个简单的解释:Sun 并不是一个实力超群的公司。Java 创造于互联网繁荣时期,而那个时候 Sun 正在出售 Sparc 业务。

        之后,互联网经济不景气,Sun 决定持续加大其在硬件业务中的投入。Sun 比较擅长创建生态系统,但它就是无法创造出用户需要的产品。Oracle 是 Sun 的后继者,擅于彻底毁坏生态系统,最终吞并/摧毁圈内的同行,还会开发出高利润的产品来取代同行。

        Oracle 曾在一份简洁的公开声明中称:“我们都知道,由于各种商业和政治原因,该版本(Java 7)花费了不少时间。”

        当然,在分析 Java 的问题上,我们还必须考虑 Sun 公司的财政困难以及 Java 系统周边的东西。Sun 公司违背了其提交 Java 进行标准化的初衷,它创造了自己的“标准”委员会,即 JCP(Java 社区进程)。随着时间的推移,JCP 尽管在一定程度上已经开放,但是无论是 Sun 还是现在的 Oracle,都拥有绝对的否决权,它们可以忽略规则,做任何想要的事情。

        什么阻碍了 JCP?不是开放性,而是利益冲突。我记得当时参与 EJB3 规范制定的某个供应商,它习惯延迟规范的进度。这是为什么呢?这些供应商需要购买或开发一个产品来集成到它们的应用服务器中,如果下一代 JavaEE 规范已经发布,那么它们也必须尽快推出产品,它们不希望比市场晚。

        协调产品的发布,对于一个公司来说都有些难,更不用说几个公司了。因此,我认为 Java 最大的问题并不是由于 JCP 造成的。

        抛弃或分离一些东西

        Sun 已经成为了过去时,现在 Oracle 是“老板”,那么为什么 Java 版本的发布周期仍然需要这么长?最简单的解释是——Java 太大。大项目往往意味着进展比较缓慢,且充满风险。下面我们就来看看如何将 Java 变得小一些。

        首先,Oracle 必须摆脱其“心爱”的客户端技术。当然,目前还没有更好的 Swing 和 JavaFX 的替代品,但是使用这些技术意味着需要把你捆绑在 Oracle 的平台上——至少目前是这样。

        我尚不清楚,目前 JavaFX 或客户端 Java 为 Oracle 带来的战略上的意义是什么,它们似乎被设计用来和 VB6、Flash 或一些 4GL(第四代语言)进行竞争的。在现代的、多平台的环境中,大部分人会认为触摸和滑动操作会更酷一些,而 JavaFX 与这种趋势是不相匹配的。为什么我们需要使用客户端 Java 来阻碍服务器端的发展,并且还有可能伴随着各种风险,比如持续数月的 Java 零日漏洞安全问题以及关于如何禁用 Java 的讨论。

        如今 Java 语言已经不再和 Java 平台一样重要。从 Java 平台中砍掉 Java 语言,并根据自己的时间表进行发布,这对于 Oracle 来说可能更容易——Oracle 推出的开发工具不是 Java 业务的重要组成部分,并没有为大部分的 Java 开发者所使用。

        Java 平台上有多种语言,比如 JRuby、Scala 等等。以高性能和可扩展的方式来支持这些语言和技术,对于云计算来说非常重要。如果云计算是未来,那么 Oracle 应该首先考虑 Java 平台。而目前所支持 Ruby、Scala、甚至 Node.js 的 Java 平台似乎是一个“锚”,而不是产生创新的“引擎”。

        比起 Mark Reinhold(Java SE 规范领导者,目前在 Oracle 公司),我更希望由 Charles Nutter(JRuby 创始人,目前在 Red Hat 公司)和 Martin Odersky(Scala 创始人,目前在 Typesafe 公司)来决定在 Java 平台中添加哪些特性。我并没有不尊重 Mark Reinhold 的意思,但是一些证据表明,在很多与 Java 语言合作的项目中,Java 语言拖慢了项目的进度。

        对于 Oracle 领导的 Java 来说,事情发展不会那么顺利,很多 Sun 之前的决议现在仍然在困扰着我们。我的建议是,抛弃客户端 Java,独立出 JVM 和 Java 语言的发布周期,致力于将 Java 作为一个平台,而不是想一次性地解决所有问题。

来自: www.iteye.com