Java和.NET交互工具JNBridgePro发布4.0版本

Java和.NET交互工具的供应商JNBridge在JavaOne 2008上发布了其核心产品JNBridgePro的新版本。

JNBridgePro是一个通用的、Java和.NET的交互工具，用来“桥接Java和.NET”，包括EJBs、J2EE、J2SE、AWT、Swing、SWT、.NET APIs、WinForms、ASP.NET及SharePoint Server。其核心产品基于.NET和Java的Remoting堆栈，并且针对调用代码在“被调用端”产生包含代理的二进制库。

JNBridgePro 4.0主要的新特性列举如下：
 

• 支持Java和.NET类之间互访问的Visual Studio和Eclipse插件
• 完全的64位支持
• 数据压缩以实现更好的性能

InfoQ有幸采访了JNBridge的CTO Wayne Citrin以了解新插件和JNBridge。

Hartmut Wilms (HW): 开发者如何利用新插件呢？
Wayne Citrin (WC): 不像我们基于GUI的独立的代理生成器，新的插件使得开发者可以直接从Eclipse中访问.NET类或者从Visual Studio中访问Java类。

插件通过将代理构建操作合并到IDE的整个构建过程中来简化代理生成过程。使用VS和Eclipse插件的情况下，代理成为另外一个项目，并且可由其他项目引用。当开发者在IDE中构建其整个解决方案时，IDE会确定依赖于代理项目的.NET或Java项目，然后构建代理并且在依赖于代理的项目的构建过程中使用代理项目（代理dll或者jar文件）的输出。

作为一个例子，我们来考虑这样一种情况：创建.NET应用的开发者需要访问Java API。在Visual Studio中，该开发者需要创建一个JNBridge项目，打开编辑器并指定需要访问哪些Java类。接下来该开发者为.NET应用（使用C#、VB.NET或者其他.NET语言）创建项目，引用代理项目，然后开始编写代码。当该开发者构建项目时，会自动生成代理dll，然后在该.NET应用的构建过程中使用它。


HW：JNBridgePro应用在Java和.NET的什么版本上？
WC：JNBridgePro应用在.NET框架1.0、1.1、2.0、3.0及3.5和JDK 1.3.1及后续版本上。

JNBridgePro插件支持.NET框架2.0及后续版本以及JDK 1.4及后续版本。JNBridgePro独立的GUI依旧可用，它支持.NET框架和JDK的早期版本。


HW：因为.NET框架4.0可能会对CLR有所改变，同时未来的Java版本也可能向JVM增加新的变化，那么对JNBridgePro来说会产生什么影响呢？
WC：只要新的CLR和JVM是向后兼容的，那么在新的版本中使用当前的JNBridgePro就不会出现任何问题。如果加入了新的二进制格式，我们就会开发针对新格式和框架的JNBridgePro的新版本。例如，当.NET从1.1升级到2.0时我们就是这么做的。在.NET 2.0发布前，我们开发了针对.NET 2.0 beta版的JNBridgePro 3.0，当.NET 2.0成为GA版时，我们在同一个月就发布了JNBridgePro 3.0。

当一个平台（.NET或Java）加入了我们想利用（.NET 2.0或Java 5）的新的APIs时，我们就会开发可以使用这些新特性的新版本。对于Java来说，我们想让Java端的组件既能工作于Java的早期版本，又能工作于Java 5，实际上我们是针对Java 1.3和1.4来进行编译，然后使用反射来访问新的APIs。对于.NET 2.0来说，新的二进制格式意味着针对1.x和2.0的单独的一套二进制代码已经不再可行了，所以我们针对每个版本都开发了相应的.NET组件。

至于.NET Remoting，微软已经表明他们会在未来的几年中继续支持Remoting。我们会根据微软的发布计划进行更新，如果我们发现在未来的.NET框架的alpha或beta版中已经移除了Remoting的话，我们当然会迁移到WCF了。


HW：当谈及到互操作时，大多数IT工作者都会想到Web Services和SOA。JNBridgePro处在什么位置上呢？
WC：相对于Web Services，JNBridgePro有如下优势。
 

• JNBridgePro的TCP/二进制和共享内存机制要比Web Services快几个数量级。
• JNBridgePro更适合访问扩展的面向对象的API，这与Web Service面向服务的方式正好相反，Web Service的这种方式会大大缩小访问点集合。在某些情况下，缩小的面向服务的方式是恰当的；但对于另外一些情况，JNBridgePro的面向对象的方式更加适合。
• 很多应用和库并不是面向Web Services的，并且在另外一些情况下，在同一台机器上或者同一个线程中使用Web Services去访问简单的库显得大材小用。JNBridgePro可以轻松应用到任何应用上，并且其共享内存机制对于同一台机器的访问是非常适合的，而Web Services在这种情况下就显得有些不合时宜。
• 实现Web Services是一个战略上的决定，通常需要来自组织的不同部门的决策者的批准才行。要想获得这个批准可能需要花费大量时间，并且很有可能还需要高层的批准。相反，JNBridgePro可以看做是战术上的解决方案，它允许端到端的交互，而这可能只需要开发者或者架构师级别上的人同意即可，并且实现这个是非常快的。当然，JNBridgePro也可以用在战略上，因为它具备了上面提到的一些优势。

HW：JNBridgePro 4.x的路线图如何？
WC：我们计划从我们的客户那里找到4.0版的发展方向并且在未来版本的开发中考虑他们的反馈。我们正在考虑的一些特性包括在tcp/二进制机制中对SSL通信更加广泛的支持，并且支持如ref和out参数（只在.NET中存在，Java中不存在）。我们还会考虑针对.NET和Java的特定技术（因为有的用户只想通过这些技术来简化交互，而并不想利用整个Java或者.NET平台）来制定JNBridgePro。当然，我们还会一直关注.NET和Java平台的新版本中将要增加的新特性。


HW：非常感谢您能接受我们的采访。