.net框架原创作者：Ashish Banerjee

翻译整理：51DOTNET CLUB（WWW.51DOTNET.COM）SLASH

目的：对JAVA与.NET框架共存的可能性做一个评估

目标受众：JAVA程序员和系统工程师

  

提要：

       首先是对JAVA 和 .NET平台的构成做一个分析，然后是我个人对JAVA如何形成的一个认识，接着是分析微软和SUN之间的合作与分歧，最后是JAVA与.NET合作的前景。

     
我个人强烈认为JAVA与.NET将在不久的未来逐步的统一起来。已经有很多关于整合JAVA和.NET的项目计划被提交到源码开放组织。在微软的MSDN，SUN 的JAVA站点，以及来自于ECMA 和 W3C.org的标准文档都可以看到有关内容。

  

简介

     JAVA与.NET继续发展下去，可能的两种结果：其中的一种退出竞争或是两种共存，而共存的可能性更大。JAVA得以生存的原因在于它的时间优势：它已经发展了六年；它在大多数的操作系统上可以运行；它得到了业界领导者如ORACLE、IBM的支持；并且使用JAVA进行开发的项目计划几乎覆盖所有的应用程序领域。


     而.NET的优势在于微软拥有90%的桌面操作系统市场，同时微软也开始采用SUN的市场战略，即将其特有的技术标准化。如：在远程通信上它向IETF（InternetEngineering Task Force）和W3C（World Wide Web Consortium）提交了SOAP（SIMPLE OBJECT ACCESS PROTOCLE）（类似于RFC-REQUEST FORCOMMENT）；向ECMA (European Computer Manufacturer's Association)提交了C#语言和通用运行时（COMMON RUNTIME）基础结构的标准。

  

JAVA平台的构架

      JAVA平台包括JAVA语言，以及一套虚拟机——如JVM、KVM、CVM等——通过它们实现在PC机，手提电脑或是嵌入式系统上运行JAVA的字节码。同时，JAVA平台还定义了一整套覆盖面很广的API，它们被用来与微软的API协调或是相互竞争。如JDBC对ODBC，JTAPI对TAPI，JDO对ADO等等。因此，简要来说，JAVA平台包括语言，虚拟机，以及API库。


      由于使用虚拟机机制，所以JAVA语言在所有的平台上只有唯一的版本，因此它使用RMI（远程方法调用Remote Method Invocation）协议进行远程通信；微软则在.NET框架中使用DCOM——正在逐步演变为SOAP（简单对象访问协议）。


      SUN最初对JAVA的宣传是“一次性代码编写，所有环境下运行”，但在推出了“J2EE” (Java 2 Enterprise Edition)和“J2ME” (Java 2 Micro Edition)后不得不收回了它最初的宣传，因为“一种尺码的鞋适合所有的脚”的解决方案并不能很好的工作。

   

.NET平台的构架

  

     .NET框架包括C++, VB.NET (VB 7.x) 和 C# 等一系列语言；与JAVA虚拟机类似的一套运行时环境；以及一套倾向与WINDOWS体系的API接口。其中的运行时环境可能存在于一个浏览器、或是一个WEB SERVER、或是在操作系统中。将来也许在SQL SERVER中也可能存在这样的运行时环境。另外需要提及的是微软的SOAP协议，它在继承了DCOM的一些特性的基础上发展起来，基于XML格式通过HTTP进行传输。SOAP的JAVA版本，可以在http://xml.apache.org上看到它的有关文档。

  

发展历程

  

JAVA最初来源于SUN的一套为机顶盒设计的语言，当时的名字是OAK，SUN将之更名，并将它放在INTERNET上作为开放源码共享。随着专门为网页设计的JAVA APPLET的出现，JAVA语言迅速在INTERNET上流行起来。当时的浏览器主要是NETSCAPE。当微软发现明天市场的主宰可能是浏览器而不是桌面系统时，开始着手对NETSCAPE进行收购，在收购计划失败后微软发展了自己的浏览器IE。



当时的INTERNET需要一种语言，而JAVA适时的出现了，由于它与C++的许多相似的语法，使得很多程序员转向了JAVA。而它确实具有很多优势，以至于在98年秋，它的反对者微软在MSDN中都宣称，JAVA是编写COM组件的最佳语言。


随着JAVA一起出现的还有LINUX操作系统和APACHE服务器。这三者的联合在服务器端的应用表现出强大的威力，以至WINDOWS NT在企业级服务器市场受到了很大的冲击。


98年出现的DHTML和JAVASCRIPT导致了JAVA APPLET在网页设计领域的淡出，在这里有两方面因素：一、大部分APPLET效果现在都可以由DHTML完成；二、而DHTML对带宽的要求更低。但是JAVA因为在服务器端的应用仍有市场，而得以继续发展。这是开发源码的支持者为JAVA添加了活力，首先是APACHE提出的SERVERLET 和 稍后出现的JSP，这些在.com网站的程序开发中占据了一席之地。


JAVA平台首先以SERVERLET，然后是JSP，最后是EJB(Enterprise Java Beans)，逐步向企业级应用拓展。EJB是一个面向对象的事务进程系统，有些类似于微软的MTS（Microsoft Transaction Server）。事实上MTS和EJB都不是很成功，因为它们都无法达到INTERNET应用的规模。


     就我的观点来看，JAVA最失败的时刻是，SUN通过法律手段向微软索赔$2000万，并获得成功的时候。微软从那时开始制订自己的.NET计划，同时也宣布了JAVA作为独一无二的INTERNET 平台的地位的结束。

  

展望


现在，我们能看到到还只是一个很混乱的局面。而在未来，我们将看到.NET的成熟，以及它和JAVA的融合。


JAVA将继续保持它的特点：跨平台的服务器端应用，如WAP服务器，或者是电信领域的如JAIN(Java API for Intelligent Networks，同时它在嵌入式系统中将继续保持它的优势，象智能卡、移动电话、PDA等。而我们还将看到.NET的成熟，当然这种成熟需要时间，可能是相当长的一段时间，就好象当年JAVA成长那样。


ORACLE 8i 及其更老一些的版本，充当着一个JAVA 运行时的载体的角色，这使得JAVA 得以与ORACLE 数据库引擎紧密结合；同样，.NET体系也会与新版本的SQL SERVER，紧密的结合，这将包括一个VES （虚拟执行系统）执行引擎。这将使程序开发人员可以在SQL 语句和存储过程中嵌入C#和VB.NET 的成分。目前，你可以通过调用DLL函数来使用扩展存储过程，但数据库本身并没有一个面向对象的运行时引擎与之相匹配。

  

未来的标志.NET 成熟的里程碑

   

非微软产品，包括服务器，桌面或是便携式设备的操作系统如Solaris, Linux和Palm OS的.NET接口。与JAVA核心的整合。比如说，针对CLI（Common Language Infrastructure）的JAVA编译器，针对JAVA虚拟机的C#编译器。SQL SERVER 或是 ORACLE 等数据库产品中整合的VES 引擎。由中立的第三方开发的开放源码的，完善的.NET平台。


可以预见到，微软将会赞助一些开放源码的项目，以使.NET 向UNIX 平台扩展，而这将有助于一些开放源码组织减少它们对JAVA的偏爱。

  

JAVA的命运

  

     JAVA的一个主要目标是通信设备提供商，如NOKIA就在它的WAP SERVER 应用了JAVA。类似于70年代和80年代初，PC销售时硬件供应商将最终的应用程序绑定在操作系统中一起销售，JAVA现在也被绑定于通信设备中被销售。

     
它的另一个主要方向是JAIN（Java API for Advanced Intelligent Network），它主要是定义一套与协议（如CDMA，GSM，IMT2000）无关的API，以便于基于开放市场的组件开发。这使得ISV（独立软件供应商）可以以插件的形式提供通信服务，如可自动转接至最近的可拨通的国际呼叫中心的800免费电话。当然，JAIN也遇到了对手，想微软和不列颠通信提出的Parlay计划——它也被业界所支持。

    
另外，JAVA在嵌入式设备中也保持着领先的地位，如smart 3G 和 GPRS，在这里的移动电话系统采用的是J2ME（Java 2 Micro Edition），但是如果它不能很好的解决一些固有的问题，如载入时的延迟等，也许，很快，它就将被C#代替，如果.NET 能提供快速的运行环境，和广泛的业界支持。

  

.NET和JAVA的整合

   

无论从商业角度，还是开发者角度，甚至是源码开放组织的角度，.NET和JAVA的整合都显得很有必要，下面就二者的整合做出一个提前的估计（所有的相关项目被分为A、B、C三个组，以便于看清它们之间的关系，当然这些项目也完全可以被独立的操作）：

JVM to CIL compiler (Group A)

Java API bridge for .NET API and lib. (Group A)

Java compiler for CLI (Group A)

CLI ports for Palm OS, Linux and Solaris (Group B)

.NET API and lib. bridge for Palm OS API (Group B)

.NET API and lib. bridge for POSIX (Group B)

CIL compiler to JVM (Group C)

.NET API and lib. bridge for Java API (Group C)

C# compiler for JVM (Group C)

    

A组的项目


    该组项目的主要目的是使现有的JAVA二进制代码能够在.NET平台上被执行。这意味着JAVA的二进制码（后缀为class 的文件）不用再从源代码进行重编译就能运行于.NET 平台了。当然这些class 文件在安装或执行时会被编译，就好象微软的运行时和JIT对微软中间语言所做的那样。

JVM to CIL compiler

     一个编译器，输入JAVA字节码，输出MSIL代码——它将被编译为可执行文件（如EXE，DLL，MSI等）

  

Java API bridge for .NET API and lib

     
在这里，JAVA API 与每一个相应 .NET API之间将建立一个映射，比如Java API中的java.io.File将被映射到 .NET的System.IO.File 类。相对于比较简单的IO类的映射，还有一些映射比较复杂，比如java.net包到.NET 的SYSTEM.NET的映射。这里存在的一个问题是：该项工作如果在C#中进行开发会比较方便。而假如在JAVA中实现，则需要有一个直接指向CLI（Common Language Interface）的编译器，它能生成符合CLS（Common Language Specification）标准的CIL（Common Intermediate Language）代码。

    
可以通过编写一个向导式的工具来避免一些烦琐的工作，例如，可以利用C# 或JAVA来编写一个基于XML格式的对象描述，用它生成一个框架代码，然后根据需要向其中手写添加其他代码。如果你确实打算进行这样的操作，在http://xml.apache.org站点你可以找到很多有用的资料。微软的过时的JAVA SDK中也有类似的工具可供参考——一个用来生成Jdirect（JDirect was the Microsoft's hack for implementing native interfaces）代码的工具，利用它可以实现访问本地WIN32 API。SDK中有该工具的源代码。顺便提一句，由于这里涉及到微软的一套独特的JAVA扩展标记，因此SUN和微软一直就此问题打着官司。

  

Java compiler for CLI

     它将JAVA源代码（使用.NET 框架API）编译为可执行文件的格式，如EXE，DLL等，这个工作是在最高的层面上对JAVA和.NET框架进行整合。这将为今后直接利用JAVA在.NET框架下创建应用打好基础。

     
对现有JAVA编译器的代码生成部分重写，将是此项工作一个比较便捷的解决方案。就我个人的意见，SUN会根据开放源代码的标准，开发这样的一套编译器。当然，这样的一些改造计划需要对一些JAVA类进行调整。

  

B组的项目

该组的项目将主要致力于为其他的平台如PALM OS、SOLARIS以及LINUX平台开发.NET 框架的端口。这些端口应该用C 来编写以适应速度和控制上的需要，另外采用       C 来开发还可以保留进行操作系统相关的系统级编程。


CLI ports for Palm OS, Linux and Solaris.

这部分内容事实上分为两个独立的部分：一、针对PALM OS；二、针对UNIX 系统。


对于PALM OS 来说，解决方案比较简单，开发可以在PC 环境下进行，然后利用数据线或是蓝牙传输到PALM 设备上。与之相关的.NET 框架针对PALM OS 设计的 API 将在下个部分详述。

    UNIX部分将利用JAVA开发，最后将PE（Portable Executeable）文件编译为COFF（Common Object File Format）格式，一种UNIX 可执行文件的格式。编译将在安装或是载入时进行。

  

.NET API and lib. bridge for Palm OS API.

这个.NET API bridge 应该以一种优化的方式被映射到PALM OS API上。连接器和装载设备的映射表驻留在PC 的网关上。通过数据线或蓝牙传输PALM OS 的可执行代码。它的实现将依赖于PALM OS 的驻留虚拟机 KVM（the Java 2 Micro edition）运行时，同时它还应该避免KVM设计中JAVA运行程序载入过慢的缺陷。另外这一套API 与 为WINDWOS CE 的 设计的不同，它不应舍弃那些资源占用较大的API 象System.Xml。.NET依赖于SOAP进行远程的方法调用。SOAP 基于 XML格式，因此它需要System.Xml的支持。如果没有，基于SOAP的分布式应用将无法工作。通过调用System.Xml API 的方法可以实现对PDA诸如WINDOWS CE 和 PALM OS上的应用程序或是一些服务器端的应用的远程操作。甚至可以在SOAP的基础上利用为WAP (Wireless Access Protocol)设计的WBXML (Wap Binary XML)标准与WAP 网关进行通信。

  

.NET API and lib. bridge for POSIX.

     这部分将对.NET API 和UNIX API进行映射，大量的 C 的编程工作将是一个困难，但更大的困难将来自于GUI 元素的处理上。这些UNIX平台会有很多GUI框架，比较安全的做法是给它们提供一个WIN32 API 的端口作为媒介。如果能以前文所述的MICROSOFT JAVA SDK的方法来进行映射的操作，那么将节省大量的编程工作。

  

C组的项目

  

该部分的内容致力于将.NET 框架应用于JAVA上。这将是一项艰苦的工作。当然，假如微软向ECMA提交一份标准规范，这项工作将变的比较实际一些。

  

CIL compiler to JVM

该项目将把.NET执行程序（PE）转换为.class格式的文件。但如果执行程序中有一些非受管代码，JVM将不接受它们。该项目的实现依赖于下面将要描述的.NET API bridge for Java 的实现。

  

.NET API and lib. bridge for Java API.

  

一个完全兼容的.NET API bridge几乎是不可能的，它需要依赖于微软向ECMA提交的标准中的一些参数。这项工作将由JAVA来实现，但与前文提到的Java API to .NET bridge一样，将有很多烦琐的工作。

  

C# compiler for JVM

   这项工作可以用JAVA或是C# 的任意一种来完成。比较容易实现的是利用JAVA，因为有SUN的JAVA编译器的许多代码可以被再利用。但我建议用C# 来实现该项工作，在.NET 框架中有许多基础的编译器可被利用。此项目依赖于.NET API bridge for Java的实现。

  

总结

    最后我要说的是将.net 与JAVA 整合不仅仅是微软与SUN的工作。所有的程序员也许都应对它进行关注。