Java 和.NET 继续争斗的四大相关问题
阅读次数: 945 次 发布时间: 2010-01-05 09:51:14 发布人: 不详
来源: 51CTO 在本篇文章中,著名程序员 Justin James 讨论了 Java 的未来,以及 Java 与.NET 的开发成本对比, 和 Java 是否能够取代.NET。Justin 在文中总结了四大要点,重点关注了两个运行时在性能和成本上的异 同之处。 1、Java SE 7 遭遇.NET CLR 会发生什么? 从 Java SE 7 的功能
列表中可以看出,它相比以前版本有了长足提高。那么,它是一个游戏改变者吗? 我认为不会是这样。在过去数年中,JVM 和.NET CLR 都发生了众多改进;过去那些只有技术非常高超的程序 员才能完成的许多事情,现在借助于 JVM 和.NET CLR 的增强功能,普通
程序员也能够做得到。 尽管 JVM 和.NET CLR 并非在同一个时间实现相同的想法,但是如果在一方出现了某个好的想法,另一 方也会迅速跟进,这一点不仅仅体现在运行时层面上。举例来说,对于 Java 来说,Hibernate 项目取得了 巨大成功后,.NET 也迅速推出了 NHibernate。而.NET 的闭包(closures)功能深受众多开发者的欢迎,Java 似乎不久也将实现它们,当然,这是一个语言功能,而非运行时功能。
.NET 闭包大受好评,Java 也将迅速跟进 2、在可以预见的未来,一个运行时是否会彻底击败另一个? 尽管从技术层面上 JVM 和.NET CLR 非常相似,但它们都有自己的市场,两者的灵活性都不是很强。如 果一个人已经围绕.NET 服务器和 IIS 创建了他们的基础架构, 他不可能第二天醒来把所有这些迁移到 Java, 反过来也是这样。甚至如果一个公司决定切换自己的开发平台,那它可能需要替换整个开发团队,或者从 头开始对他们进行培训。即使培训完成后,在技能上还是存在严重的不足;毕竟,一个高级.
NET 开发者不 可能在经过 3 个月培训后突然变成一个高级 Java 开发者。 另外,公司需要保留现有技术人员来维护已有的代码。你认为这些员工会坐视他们的职位被取消,或 者他们的技能将变得无用或贬值吗?当然不会。对一个公司来说,完全从 Java 转向.NET 或完全从.NET 转向 Java, 都是一种自杀行为。 最多是通过一个多年期项目来对员工进行重新教育。 自从.NET 发布以来,
VB6 从 到.NET 的迁移都已经花了 8 年时间。 程序员和项目的转型需要时间 3、Java 开发的成本是否比.NET 开发更具
经济性,如果是这样,人们是否会转向 Java 来节省投资? 如果你仅仅着眼于工具,我的答案是“既对也错。”的确,只要你愿意,你可以在一个完全开源的组 合上运行
Java。你可以采取 Linux/Tomcat/MySQL/Java 组合,或者在服务器方面使用 SpringSource 组合 (51CTO 编者注:对于 SpringSource 服务器组合,
有人却是表示不满的,可以参考这篇文章),在开发者的
计算机上使用 Eclipse 或 NetBeans。但是需要指出的是,无论出于什么原因,你都不会是开源替代产品的 狂热支持者,我并非说替代产品就不好;如果是那样的话,与.NET 工具相比,Java 工具的价格相当,在很 多情况下甚至更贵。而且从甲骨文和 IBM 等公司正在进行的业务来看,很明显许多公司认为有必要付费购 买专有 Java 工具。就价格而言,在任一指定市场领域,微软几乎总是价格最低的企业类厂商。 另外,你必须考虑到如果没有切换成本公司将会省下多少钱。一个 Visual Studio 副本的成本要远低于一 个中等收入开发者的周薪和保险金(51CTO 编者注:作者 Justin 是美国人)。而且同一个开发者学会 Java 并且达到他擅长.NET 的水平,所需要的时间要远远大于一周时间。 出于公平考虑,这种分析也同样适用于从 Java 转向.NET。相比于平台切换的痛苦,开发工具成本实在 微不足道。当然也有两种例外情况。第一种情况是新建公司,那么不存在迁移成本的
问题。在这种情况下, Java 依然不具有成本优势,因为微软也已经推