JNBridgePro 4.0 Introduces New Visual Studio and Eclipse Plug-ins

Posted by Hartmut Wilms on May 08, 2008

Sections

Development,

Architecture & Design

Topics

Java plus .NET Integration ,

Java ,

.NET Framework ,

.NET

Tags

JNBridge

JNBridge, provider of Java and .NET interoperability tools, announced a new release of its core product, JNBridgePro, at JavaOne 2008.

JNBridgePro is a general purpose, Java and .NET interoperability tool that "bridges anything Java to .NET and anything .NET to Java" including EJBs, J2EE, J2SE, AWT, Swing, SWT, .NET APIs, WinForms, ASP.NET, and SharePoint Server.  The core product is based on the remoting stack of .NET and Java and generates binary libraries containing proxies for invoking code on "the other side".

The primary new features of JNBridgePro 4.0 are:

• Visual Studio and Eclipse plug-ins for exploring and exposing Java classes form .NET and .NET classes from Java
• Full 64-bit support
• Data compression for greater performance

InfoQ's got a chance to talk to Wayne Citrin, CTO of JNBridge, about the new plug-ins and JNBridge in general.

Hartmut Wilms (HW): How can developers take advantage of the new plug-ins?

Wayne Citrin (WC): Unlike our separate GUI-based standalone proxy generator, the plug-ins enable developers to directly explore and expose .NET classes from Eclipse or Java classes from within Visual Studio.

The plug-ins will simplify the proxy generation process by incorporating the proxy build operation into the IDE's overall build cycle. With the VS and Eclipse plug-ins, proxies become just another project, which can be referenced by still other projects. When the developer builds his or her entire solution in the IDE, the IDE will determine that the .NET or Java project depends on the proxy project, then builds the proxies, and uses the output of the proxy project (the proxy dll or jar file itself) in the build of the dependent project.

As an example, consider a developer creating a .NET application that needs to access a Java API. In Visual Studio, the developer would create a JNBridge project, open the editor, and specify which Java classes will be accessed. The developer can then create the project for the .NET application (in C#, VB.NET, or other .NET language), reference the proxy project, and program against it. When the developer builds the project, the proxy dll is automatically created, then used in the build of the .NET application's project.

HW: What Java and .NET versions are targeted by JNBridgePro?

WC: JNBridgePro targets .NET Frameworks 1.0, 1.1, 2.0, 3.0, and 3.5, and JDKs 1.3.1 and later.

The JNBridgePro plug-ins support .NET Framework 2.0 and later, and JDK 1.4 and later. JNBridgePro's stand-alone GUI is still available, and supports the earlier versions of the .NET Framework and JDK.

HW: As .NET Framework 4.0 might incorporate changes to the CLR and future Java version might introduce changes to the JVM,  what will be the consequences for JNBridgePro?

WC: As long as the new CLR and JVM are backward-compatible, there should be no problem using the current JNBridgePro with the new versions. If a new binary format is introduced, we will introduce a new version of JNBridgePro targeted to the new format and framework. For example, this happened when .NET went from 1.1 to 2.0. Prior to .NET 2.0 being released we developed JNBridgePro 3.0 against beta versions of .NET 2.0, and released JNBridgePro 3.0 in the same month as .NET 2.0 became GA.

When a platform (.NET or Java) introduces new APIs that we wish to take advantage of (again, .NET 2.0, or Java 5), we introduce a new version that can take advantage of the new features. In the case of Java, we want our Java-side components to work against earlier versions of Java as well as Java 5, so we actually compile against Java 1.3 and 1.4, and use reflection to access the new APIs. With .NET 2.0, the new binary format meant that a single set of binaries for 1.x and 2.0 was not an option, so we produce versions of the .NET components for each.

As for .NET Remoting, Microsoft has gone on record that they will continue to support remoting for several years to come. We follow Microsoft's announced plans for upcoming releases, and if we note the removal of remoting in the alpha or beta version of an upcoming .NET Framework version, we will certainly migrate to WCF.

HW: When talking about interoperability most of the IT world thinks Web Services and SOA. What's the positioning of JNBridgePro?

WC: There are several advantages to using JNBridgePro over Web Services.

• JNBridgePro's TCP/binary and shared-memory mechanisms are orders of magnitude faster than Web Services.
• JNBridgePro is better suited to accessing an extensive object-oriented API, as opposed to the service-oriented approach of a Web Service, which exposed a much narrower set of access points. For some purposes, the narrower service-oriented approach is appropriate; for others, JNBridgePro's object-oriented approach is more suitable.
• Many applications and libraries are not Web Services-enabled, and in other cases, using Web Services to access a simple library on the same machine or in the same process seems like overkill. Just about any application can be easily enabled for interop using JNBridgePro, and JNBridgePro's shared-memory mechanism is appropriate to single-machine interop where Web Services are an excessive solution.
• Implementing Web Services is a strategic decision that typically requires approval of many stakeholders from different parts of the organization. Getting this approval can be time-consuming, and likely will require approval at a high level. JNBridgePro, on the other hand, can be used as a more tactical solution, allowing point-to-point interoperability that may only require approval at the level of the developer or architect, and also where it is considerably faster to implement. Of course, JNBridgePro can also be used in strategic contexts, where it has other advantages mentioned above.

HW: What's next on the roadmap for JNBridgePro 4.x?

WC: We plan to step back and see how our customers receive version 4.0, and to incorporate their feedback in developing future versions. Some features we are looking at include more extensive support for SSL communications in the tcp/binary mechanism, and support for features like ref and out parameters that exist in .NET but not in Java. We may also examine targeting JNBridgePro to specific technologies on the .NET and Java side (in order to accommodate users who wish to simply interoperate with these technologies and not with the entire Java or .NET platforms). And of course we will be looking at new features introduced into upcoming versions of the .NET and Java platforms.

HW: Thank you very much for your time.

Information on JNBridgePro can be found on the JNBridge web site. In addition to the core product JNBridge also offers a JMS Adapter for .NET and a JMS Adapter for BizTalk Server.

• Older >