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

  • Hartmut Wilms
  • 张龙

2008 年 5 月 22 日

话题:Java.NET语言 & 开发架构

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  

Java.NET语言 & 开发架构