Net和Java.doc

.Net和Java有何相似之处2. .Net的许多技术，至少是部分上，显然受到了Java的推动。3. Java 和.Net之间的相似之处一般很明显。比如，在ASP.Net和JSP中，页面都是预编译过的，因而运行起来更快。4. “典型微软模式”-模式之一是微软赋予了开发者很大的自由，甚至是进行危险操作的自由。例如，在C#中，微软提供了一些开发者想要或需要使用的不安全语言特性。微软为已有的保留代码提供了额外的优先级，允许新开发的程序与它进行交互，这样使得它们的.Net版本不可避免地存在后门。另外一个模式是支持多语言。5. 新的.Net平台使用虚拟机的概念表示微软至少承认Sun在此领域的正确性。虚拟机是一个经典的老的概念，是Sun创立了这一基本理念。6. 除了基本系统体系之间的相似之处外，Java和.Net之间还有许多互相模仿的地方。如Java 2 Micro Edition和Microsoft .Net Compact Framework，都设计成压缩平台。还有微软的活动数据对象（新平台中的ADO.Net）和Sun的Java数据对象(JDO)，它们都提供了对数据库的简易访问。7. 随着时间的流逝，Sun的发展不可避免地会受到.Net的影响，可能会出现Scott McNealy所说的.NOT。微软在整个基于XML的Web服务上占有明显的领先地位，Sun的用户必定要求类似的东西，因此就形成了Sun ONE（开放网络环境）。令人惊奇的是，Sun的Web服务市场口号听起来与微软的Web服务市场口号竟如此相像Java最吸引人之处，在于跨平台。而.NET可以看作Java的改良版，囊括Java大部分的优点，所以当然也具有跨平台的潜力。但是认真追究起来，Java和.NET的程序其实也不算真正跨平台，因为Java VM（虚拟机器）和.NET VM本身就是一个平台，而Java程序只能在Java VM上执行，.NET程序只能在.NET VM上执行，至于VM的底下是什么操作系统，则无关紧要。 更清楚的说，Java和.NET的跨平台，指的是跨“操作系统”平台。所以，Java VM和.NET VM能移植到什么OS平台，Java程序和.NET程序就能跨到什么平台。从1.0版至今，Java历经了近多年的发展，Java已经无所不在了。除了在服务器上已经取得压倒性的胜利之外，在桌面系统的安装比例也已经超过90%（2002年的数据），且随着最近Dell等大厂和Sun签约在PC上预先安装Java VM，此数据未来会更高。 但事实上，Java跨平台的开放程度并不若我们所想象的美好，主要的原因在于“四不一没有”： 版本不一致：许多操作系统上虽然已经具备Java VM，但是版本并未和最新版的Java VM同步，甚至不同版本差距颇大者。举例来说，早期Mac OS在追随Java的脚步上，步伐很慢，往往差了一个版本，例如在Java 1.3推出一、二年后，Mac OS仍只有1.2版的Java VM可用（但是现在Mac OSX已经追上Java的版本推进）。另外，Java VM安装比例固然已经超过90%，但是其中应该有许多仍是使用IE浏览器内建的Microsoft VM（只支持到Java 1.1.4 API），不能执行1.2以后的Java 2程序。所幸的是，版本落差这个问题近来已经有显著的改善。 特殊动态链接库不存在：对于那些非J2SE标准的动态链接库（例如Java 3D），往往只局限在Window、Solaris、Linux三个操作系统。关于这一点，我不认为未来几年内会有所改善。 标准不够开放：Sun曾经把Java提交给ISO来制订开放的标准，但后来又因为舍不得而撤回，改成立JCP委员会为Java的标准制订单位。这也使得Java在开放程度上并未如宣传上所说的那么好。（这一方面，.NET还比Java好一些，至少核心部分已经是ECMA的标准）。 厂商不服气：这可能会造成标准的分裂。早期微软在Visual J+产品中就有一些可能造成Java分裂的举动出现。近年来关于IBM和JBoss等公司，在J2EE的产品上，和Sun也是屡次发生冲突。甚至之前传出某公司有利用市场的力量，另立标准的可能。例如Eclipse的SWT就是一个和Java的AWT/Swing互相竞争的API。 技术人员没有跟上新技术：过去这八年，Java修修补补，废弃了一些旧的API和程序设计思维，增加了许多新东西。如果开发人员未能随时补充新知识，仍用旧的方法开发系统，就会横生困扰。这其实是很严重的问题。.NET在跨平台问题也不少： .NET某些API在设计时，并没有考虑到跨平台的需求，例如Windows Forms就是如此。这会使得移植.NET VM到不同操作系统时，难度会比较高。Mono（Linux上的.NET VM）曾想移植Windows Forms到Linux上，但是后来放弃了，改成在Wine上面执行Windows Forms（当然效率会因此变差了）。但是再后来由于System.Drawing实现的比较好，因而又基于System.Drawing来实现底层的SWF，Mono 1.2的发布就是等着SWF1.0的发布。当然效率肯定比不上Windows下的SWF。不过Mono是推举使用GTK#的 只有核心部分是ECMA的标准，重要的API例如ASP.NET，和ADO.NET都不是标准，而是微软私有的财产，可能涉及法律问题。Mono另外推出Gtk#这套GUI的API（将Gtk+包装起来）。 技术人员没有跟上新技术：.NET经过了5年的发展，最新到来的2.0版本和1.x版本相比较，修改、增加了许多API增加了许多新东西,程序设计的思维也发生了重大的变化。如果开发人员未能随时补充新知识，仍用旧的方法开发系统，就会横生困扰。这其实是很严重的问题,MS的WebCast做的非常好,在帮助技术人员跟上新技术方面MS做的比SUN要好许多。 目前微软有提供一套开放原始码的.NET VM，名为Share Source Common Language Infrastructure，简称SSCLI，代称Rotor。SSCLI仅供爱好者研究使用，不做商业发行（微软商业版的.NET VM是.NET CLR）。SSCLI可以在FreeBSD、Windows、Mac OS X等平台上执行。 为了让.NET能够摆脱微软的控制，除了由Novell/Ximian资助的Mono计划之外（Mono是西班牙文“猴子”的意思）， GNU（自由软件基金会），也有一个DotGNU Portable.NET的类似计划。如果Mono和DotGNU Portable.NET等计划能成功，那么.NET的跨平台才能显露曙光，现在有许多的Linux发行版本都内置了Mono平台，如 Novell Suse Linux系列操作系统。 .NET以后是一定会流行的，至少会在Windows和Linux上成为主流。Linux和Mono得到Novell公司的大力支持，相信在不久的将来.NET将在Linux平台称为开发的平台。为了让Java能够跨进.NET的世界，有人设计了.NET VM上的Java VM，“IKVM.NET”正是这样的一套Java VM。仗着Java VM和.NET VM有许多相似之处，IKVM.NET在设计上就可以取巧，许多机制（例如垃圾收集）直接利用底下的.NET VM，不需要自己完成。有了像IKVM.NET这样的VM，Java就可以跨到.NET平台上，不失为一个扩展势力的好方法。 为了抢夺市场，Java和.NET阵营均使出浑身解数。Java阵营近来的脚步似乎加快了，这是好现象。而.NET阵营更是使出许多绝招，提供下面的工具： Visual J#：如果是1.1.4或更早以前的Java程序，可以直接利用Visual J#，来将Java的原始码编译成.NET的MSIL。这样的编译，成功率可以达到近100%。 程序转换工具：如果你的Java程序并非1.1.4以前的古董，而是用到Java 2的许多新特色，那么你可以利用微软提供的程序转换工具（例如JLCA），来帮助将Java程序转成.NET程序，达到鲸吞的效果。这些工具通常可以将八九成的程序代码转换成功，但是许多地方仍须手动调整。我们可以期待，未来版本的此类工具会更强大，转换的成功率会更高。 程序合作工具：既有的Java程序不可能一朝一夕改写成.NET，而转换工具也不是100%成功，那么如果能让既有的Java程序继续运作，而鼓励大家新的程序改用.NET平台，并慢慢换掉旧的Java程序，达到蚕食的效