想追赶.Net的脚步？Java面前障碍重重

　　不过事实上这种占用了大量资金投入的垂直技术平台应该被直接剔除并宣判其死刑，因为它对于解决主要矛盾根本毫无贡献。甲骨文甚至有可能将其添加到其它灾难性方案中，例如Java ME，并将其命名为Ordroid。如果甲骨文买下黑莓、将其重组为麾下的新部门并打出“未来的平台方案”以及“iPhone终结者”之类的唬人口号，投资者们也只会将其视为虚张声势的愚蠢方案。

　　简单来说，Java语言对于Java平台已经不再像过去那么重要。另一大负面因素在于，微软的介入削弱了Java的独有性，这种不利局面即使在2007年之后的实践协调活动中也未能得到扭转。对于甲骨文公司来说，将Java语言从Java平台中剥离出来并为其单独规划日程安排会更加轻松——毕竟甲骨文推出的开发工具既不属于Java相关业务中的主要组成部分，也没能得到Java开发人士的广泛支持。微软需要考虑Visual Studio版本是否能与下一代.Net以及C#版本相协调，但甲骨文则不必为此担心。

　　Java平台支持多种编程语言，从JavaScript到JRuby再到Scala不一而足。此外，以高性能及可扩展方式支持这类不同技术对于云计算非常重要。如果云计算将成为未来的发展方向，那么Java平台与甲骨文都需要提前做好准备。目前，Java与甲骨文已经对这一趋势表示默认。在我们看来，对Ruby、Scala甚至Node.js的广泛支持已经成为Java平台的最大特色。然而正因为如此，目前Java平台更多被视为一种立足根基而非创新引擎。

　　在为Java平台选择合适的支持语言类型方面，我更信任Charles Nutter(JRuby/红帽)与Martin Odersky(Scala/Typesafe)而非Mark Reinhold(Java SE规范/甲骨文)。我对Reinhold先生绝无丝毫不敬之意，而且已经有证据表明众多协作尝试正在进展当中，不过等待Java语言或其它甲骨文附属项目的发展实在耗去了太多时间。

　　对于甲骨文在Java领域的领导权来说，这是充满挑战的一年。Sun当初做出的许多决定开始回过头给使用者带来困扰。我给出的答案是放弃Java客户端、将JVM与语言的发布周期分离开来，同时专注于将Java打造为一个平台而非万能性解决方案。

　　本文转载自其它媒体，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!