当第一次读到一篇关于ASP+的文章时，我确实深受震动。现在ASP+称为ASP.Net，当然，它是.Net系列技术，是微软动态服务器页面的下一代版本，它提醒了我Sun公司的Java服务器页面（JSP）对微软的技术哲学体系发展所产生的积极影响。当我开始仔细研究后，我注意到.Net的许多技术，至少是部分上，显然受到了Java的推动。
当然，这没有什么让人惊奇的，我可以认为这无关紧要，过去，许多规则已经发生了改变；JSP自身在动态Web页面领域早已取得了一席之地，它最著名的产品就是ASP(也是最早的产品之一)，J2EE受到微软事务处理服务器的重要影响，其派生的产品正是COM+套件之一。可能所有情况都是这样的，很多公司都曾做过多年前IBM公司已经做过的事情，也许这正是计算机业的普遍现象。
Java 和.Net之间的相似之处一般很明显。比如，在ASP.Net和JSP中，页面都是预编译过的，因而运行起来更快。如果要寻找它们之间的差异，你可以发现典型的微软模式，尤其是在开发工具中表现得更明显。（有些人可能会对“典型微软模式”的说法发笑，但他们采取这种做法的原因之一是这么做能够取得成功）。
模式之一是微软赋予了开发者很大的自由，甚至是进行危险操作的自由。例如，在C#中，微软提供了一些开发者想要或需要使用的不安全语言特性。Java的创始人James Gosling最近讽刺了这些后门，比如程序员创建当前指示器的能力，但人们对此却无能为力。如果让开发者在不使用Java的条件下，完成在Sun中利用Java开发的任务，这样所导致的困难还是可以让用户接受的。微软为已有的保留代码提供了额外的优先级，允许新开发的程序与它进行交互，这样使得它们的.Net版本不可避免地存在后门。
另外一个模式是支持多语言。.Net出现之前，微软批评Java让程序员使用一种语言完成所有事情。实际上，微软在他们的Java虚拟机中做了一些改变（根据Sun提出的要求），使其支持与其它语言的交互。在设计自己的.Net虚拟机时，微软令它可支持多种语言。例如，不同语言对数据类型有不同的物理格式，如果不同语言需要与同一个数据进行交互时，他们会不得不违反自身内部制订的标准。如，COBOL中的字符串类型长度是固定的（按照已建立的长度标准）， C中的字符串类型是变长的，如果编译器遵守标准，那么代码就不能完成交互；如果微软制订特殊的.Net数据类型，那程序员要完成交互的话就必须要修改代码。微软采取的这种做法，让人们至少可以在.Net上用COBOL写代码，然后调用已有的程序，从而不必对COBOL程序员进行Java培训并重写代码。
但是很显然，新的.Net平台使用虚拟机的概念表示微软至少承认Sun在此领域的正确性。虚拟机是一个经典的老的概念，是Sun创立了这一基本理念。我走出大学校门的第一份工作是编写在UCSD p-System上运行的代码，我的二进制程序通过虚拟机在相差很大的硬件和软件平台上运行，但过去处理器速度只是几兆赫兹，高端系统只拥有1MB RAM，因此虚拟机程序运行起来非常慢。现在的虚拟机，如Java虚拟机或.Net虚拟机的运行速度得到了提高，用户可以接受这种速度。
除了基本系统体系之间的相似之处外，Java和.Net之间还有许多互相模仿的地方。如Java 2 Micro Edition和Microsoft .Net Compact Framework，都设计成压缩平台。还有微软的活动数据对象（新平台中的ADO.Net）和Sun的Java数据对象(JDO)，它们都提供了对数据库的简易访问。
随着时间的流逝，Sun的发展不可避免地会受到.Net的影响，可能会出现Scott McNealy所说的".NOT"。微软在整个基于XML的Web服务上占有明显的领先地位，Sun的用户必定要求类似的东西，因此就形成了Sun ONE（开放网络环境）。令人惊奇的是，Sun的Web服务市场口号听起来与微软的Web服务市场口号竟如此相像！
看了这篇文章后，你可能简单地认为这两家公司不太尊重对方，但我认为事情要比想到的更复杂更有意义。我希望.Net和Java在今后的时间里能互相“影响”，两个公司都能看到对方值得借鉴的地方。这就是竞争！
