是否能让JAVA 和 .NET框架共存（转）

<script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>

<script type="text/javascript"> </script><script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>

原创作者：Ashish Banerjee

翻译整理：51DOT NET CLUB（WWW.51DOT NET.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（Inter NETEngineering 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将之更名，并将它放在INTER NET上作为开放源码共享。随着专门为网页设计的 JAVA APPLET的出现， JAVA语言迅速在INTER NET上流行起来。当时的浏览器主要是 NETSCAPE。当微软发现明天市场的主宰可能是浏览器而不是桌面系统时，开始着手对 NETSCAPE进行收购，在收购计划失败后微软发展了自己的浏览器IE。



当时的INTER NET需要一种语言，而 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都不是很成功，因为它们都无法达到INTER NET应用的规模。


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

  

展望


现在，我们能看到到还只是一个很混乱的局面。而在未来，我们将看到. 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的工作。所有的程序员也许都应对它

seover="window.status='正文-- 是否能让 JAVA 和 . NET 框架共存（转）';return true">
<script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>

<script type="text/javascript"> </script><script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>