正确的响应是甚麽？

对于微软的开发商，.Net是一个好的构架，你可以将许多事情交给微软的体系结构去完成。ASP.NET比ASP好，ADO.NET比ADO和DCOM出色，但有所差别，C# 比C和C++更好。.Net最初版将在2001年的某个时候可以得到，因此你有足够的时间准备。但是可以肯定，它将成为微软平台的缺省（约定）开发环境。如果您现在正在微软的开发构架中从事开发工作，将.Net的元件采纳到你的体系结构中，肯定能够获得利益。

但是，.Net平台的几个期望目标极高，但不能保证全部起步，至少在短期内完成不了。例如IL公共语言运行时在使开发者获益之前还有某些明显的障碍需要克服。想要把每一种语言和元件运行时集成起来，必须定义这种语言的子集/超集，并清晰地影射到IL运行时上，和必须定义结构，以便提供IL需要的元数据，然后和必须开发适用于两种编译语言结构（对象、部件等）的编译器（从XML到IL和从IL到XML），集成到IL部件字节代码中，同时还要生成对现有IL元件的语言专用接口。

这里还有一些历史的因由，必须开发非Java语言到JavaVM的众多桥梁，如：Jpython、PERCobol、The Tcl/Java Project。同时，如果有足够的兴趣，几年前就应将Bertrand Meyes和一些别的Eiffel folk一起放到Eiffel-to-Java VM系统中(几年后)，只有Jpython 例外。这些工具得到广泛的采纳，甚至在他们自己相关的委员会里也是这样，即使它们似乎能够提供一种方法，用你所偏爱的语言，为Java环境写代码(虽然不是整个J2EE构架)。然而为什么还这样缺乏热情？因为人们犹豫，不想承受从它们的开发语言中，将额外的翻译工作加到目标构架上。如果Java环境是目标，人们通常会选择学习Java。我预计，对.Net也是同样正确的。人们将会选择学习C#和用这种语言写.Net的部件。

另一点要注意：基于.Net的SOAP将用于分布式通信，谨防性能损失。SOAP基本上意味着在HTTP上的XML。HTTP不是一个高性能的数据协议，因此XML隐含一个XML语法解析层，也就是需要更多的计算开销。两者相结合会大大减少相对另一种发信/通信信道的事务处理速率。XML是一种非常丰富的、十分强大的发信用的元语言。HTTP是非常灵活可移动的，因此可以防止许多防火墙的损失，但是如果事务处理速率对你是优先考虑的话，请保持你的选项打开。

 对于Java和开放资源委员会

请不要把.Net作为微软市场竞争的手段，继续以你们喜爱的方式理解.Net可能更容易接受。但是.Net并不是一种精巧的标志，而是微软策略的重大转移，将为其平台带来福音。他们正在为使其它的构架和平台在管理级上做得更好而奋斗。提供关于自身成本和无缝集成方面有用的可查询的统计资料。现在他们正努力把Java和开放资源自身所特有的元语言，逐步开放，然后力图直接满足开发商的需要。在过去一段时间里，由于他们没有做好，两件事情失败了。如果你认为自己是Java和无资源平台的福音的传播者，那么，竞争的性质就会改变。

另外，微软的IL运行时，至少可能有一个值得注意的目标：就是清除编程语言进入结构框架的障碍。Java清除了平台的障碍(当然在有限范围内，例如你不能没有硬件资源来制作软件)。但是为了用J2EE来作开发工作，你必须在Java环境下工作。而.Net是想让你使用你选择的语言来建造.Net应用程序，这是十分美妙的。尽管还有一些大问题没有解决。如：.Net中的IL方式什么时候和是否会实际上变成广泛使用的(工具)(如上所述)。不管怎样，这就表明了单语言的J2EE方式存在弱点。这个弱点的重要性可以怀疑，但是它依然存在，因此它值得Java委员会考虑。如果开发商真的认为是这样，那么就可以把力量放在Java字节代码生成器方面，以适应非Java语言，当然这需要组织和浓缩(汇总)。

再深入研究一下J2EE，立即可以得到一些结论。为了支撑该平台和.Net相较量的优势。首先XML支持要无缝地集成到结构框架中，我们且不说将XML SAX/DOM语法解析器作为一组标准服务或者在配置元件中，扩展XML的使用。这里需要XML的发信和操作处于随时可用状态。公认的做法是在JMS顶端用XML的内容发信，但是并不是所有的平台都有这种设施，XML空间是一堆杂乱无章的标准，非关键因素标准，API和DTD是你处理元语言时期望的。

但是微软已经将SOAP放在基础层，很难把某些可理解和有用的东西放到开发商手里。J2EE的倡议者需要用他们的平台做同样的事。记住一种可能性是将XML发信提供者层放在JMS的顶部。后面紧接着Java命名和目录接口或者带LDAP的JNDI、NIS和COS命名等等。这种和标准SOAP/BizTalk供应商，EBXML供应商等等的结合将是种令人印象深刻的语句(说明)。

 澄清和更正：

由于本文在2000年8月份发表的，有40位读者以他们关心.Net和J2EE对比的想法返回给我们(见读者回信)，本文作者Jim Farley筛选过这些内容，同时用电子邮件回复他们，因此增加以下的澄清和更正。

 澄清：

C#的编译特点和Java的编译特点对比似乎让读者产生混淆，为了更清楚一点，我们用另一种方法比较：C#代码总是以自然的形式运行。Java代码典型地是以解析型字节代码运行；C#可整个编译成自然代码，或者编译到公共语言运行时字节代码中，然后在执行期间逐次编译自然代码。另一方面，Java代码典型地以运行时解析型字节代码方式运行(据此，其交叉平台能力可以增长)。同时也能够以逐次编译上下文连接方式运行；也有了一些Java自然代码编译器(Jove、Bullet Train、JET等)。

作为旁注(附注)，微软要求遵循Java的约定解析性模式在这种模式中，设计用于虚拟机的字节代码，本身不用于自然代码优化，我没有看到有力的数据证明或反驳这个要求，(一般的应针对字节代码对比自然编译语言，或者特殊针对 Java对比C#)。

在回应中，有几位读者指出J2EE支持XML，这说明了这样一个事实：J2EE1.3版(现以草案方式发布)要求任何兼容J2EE的产品，必须包含Java XML SAX和DOM语法解析器。这正是我说的“把XML SAX/DOM捆绑到Java上。我已经要求他们采取进一步措施，以J2EE支持API方式直接支持XML协同工作。最理想的方法是基于J2EE的部件和服务，应让XML在某种程度上自动支持内建(对发信、接口描述、输出等)。

 更正：

我在本文中说：C#“借用了某些JavaBeans的部件概念”。这句话没有证据，正如几位读者指出，更合适的说法是“微软C#的功能多于它们本身的COM和VB模型，这是由于来自其它已有的部件模型的影响".