JNBridgePro 4.0 增加新的 Visual Studio 和 Eclipse 插件

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：非常感谢您能接受我们的采访。

可以从 JNBridge 站点上了解关于 JNBridgePro 的更多信息。除了核心产品，JNBridge 还提供了一个针对.NET 的JMS 适配器和一个针对BizTalk Server 的JMS 适配器 。

查看英文原文： JNBridgePro 4.0 Introduces New Visual Studio and Eclipse Plug-ins