News relase: Announcing New Versions of JNBridgePro and the JNBridge JMS Adapters

We’ve just announced the forthcoming release of JNBridgePro 5.0 and v2.0 of the JMS Adapters for .NET and for BizTalk Server. The bits will be available on 11/16/09, and we’ll be demonstrating the new capabilities at PDC next week in Los Angeles.

JNBridgePro 5.0 adds support for cross-platform transactions between Java and .NET in both directions.

The JMS Adapter for BizTalk Server 2.0 adds support for request/response and solicit/response messaging patterns. Both adapters have greater architecture flexibility.

Read the full press release, and download new versions on or after next Monday, 11/16/09.

Announcing JNBridgePro 7.1 and versions 3.1 of the JMS Adapters for .NET and BizTalk Server

JNBridgePro version 7.1 and versions 3.1 of the JMS Adapters for .NET and for BizTalk Server are released!

JNBridgePro now supports Visual Studio 2013, and completes the “any-CPU” feature to include specifing separate 32-bit and 64-bit JVMs in a single shared-memory application.

The JMS Adapters for .NET and for BizTalk now provide support for the JMS 2.0 specification, and a new unified installer for both 32 and 64-bit.

Download a full-featured 30-day trial today from

JNBridgePro and cross-platform transactions

From our previous blog post, you can see that we’ve announced version 5.0 of JNBridgePro, which supports cross-platform transactions. This is a feature we’re really excited about. Up until now, you could have Java code inside a Java transaction call .NET code (or vice versa), but if something happened to cause a rollback on the Java side, the .NET side wouldn’t get rolled back. With the new version of JNBridgePro, transactions on the Java and .NET sides are transparently and seamlessly integrated. If there are active transactions on the Java and .NET sides, JNBridgePro will automatically join them, so that if either side fails, both sides are rolled back, and if both sides succeed, the transaction is committed on both the Java and .NET sides.

The picture below gives an idea of cross-platform transaction bridging in action:


JNBridgePro cross-platform transaction bridging in action

JNBridgePro’s cross-platform transaction bridging will work with both .NET-to-Java and Java-to-NET (and bidirectional) projects, and it will work with any vendor’s JEE implementation.

If you’re creating financial or e-commerce software, you will likely have transactional requirements, and we encourage you to download and try the new version of JNBridgePro, which becomes available on Monday, November 16.

More information on cross-platform transactions in the new version of JNBridgePro can be found here.

JNBridgePro and Java 8

Java 8 has a couple of new features (particularly, static and default methods in interfaces) that create problems for our current JNBridgePro 7.1. We will be coming out shortly with a new version that supports Java 8 along with previous versions of Java, but if you’re currently using JNBridgePro 7.1 and are having problems with Java 8, contact us and we’ll send you a patch.

JNBridgePro 5.1 released

JNBridgePro 5.1 is released! Version 5.1 adds support for .NET Framework 4 and a plug-in for Visual Studio 2010.

JNBridgePro 5.1 supports multi-targeting toward .NET 2.0, 3.0, 3.5 and 4.0. Download a copy here.

While you’re at it, check out our revised site design. We hope you like it, and find it easier to navigate.

JNBridgePro v7.2, adapters v3.2 released

Today we’ve announced the release of JNBridgePro version 7.2, which supports Java 8 (in addition to still supporting Java 5, 6, and 7). JNBridgePro v7.2 adds support for, among other new Java 8 features, static and default methods in interfaces. In addition, v7.2 includes substantial performance improvements in .NET applications that create very large numbers (in the millions, for example) of instances of a single Java class.

In addition, we’ve announced new version 3.2 releases of our JMS adapters for BizTalk Server and .NET. In addition to using the new JNBridgePro 7.2 components, the new adapters contain enhanced diagnostics to help track down configuration and performance issues.

For more information, please see the announcement. The new releases can be downloaded here.

JNBridgePro 6.0 is available! Integrate Java & .NET in the cloud.

Whew! We’ve made our committed deadline: JNBridgePro version 6.0 is now available for download.

This new version supports Java/.NET interoperability projects where one or both of the end points are in the cloud. JNBridgePro 6.0 enables you to build and distribute integrated applications anywhere, including:

  • Intra-cloud, where both end points reside in the same cloud, either in the same or separate instances
  • Inter-cloud, where the instances belong to different clouds — even across cloud vendors
  • Ground-to-cloud and cloud-to-ground, where one end point is in a cloud instance and the other is an application running on the ground

JNBridgePro 6.0 extends its full set of interoperability features from the ground to the cloud, so now you can build integrated applications that run anywhere. Read more details and check out some sample use case scenarios.

You may have recently seen a wee bit of press about our launch. As Michael Coté from RedMonk says: “There’s so much valuable data and process locked in Java and .Net applications that can’t just be left behind in whatever cloud-y future is out there – and refactoring all of that to be cloud friendly would be an onerous task. Instead, you need tools that help modernize those pools.”

Try it out for yourself! We’re eager to hear what you think.

New Java 8 features in JNBridgePro 7.2

Usually, when new versions of Java are released, we at JNBridge don’t have much to do.  The features generally don’t have an impact on what JNBridgePro does, and things just work.  Sometimes, as with variable-length argument lists (introduced in Java 5), they are simply syntactic sugar and are automatically proxied into their underlying form (an array).  Other times, new features occur behind the scenes (for example, lambda expressions in Java 8) and are never exposed to .NET users through proxies, so JNBridgePro doesn’t need to worry about them.

Java 8, however, contains two new features, static interface methods and default interface methods, that do affect JNBridgePro functionality. Both features are designed to improve usability of the language (whether or not they do is debatable, but that’s a topic for another blog post).  Static methods in interfaces are designed to add additional functionality to an interface, in the same way that static field constants have existed in Java interfaces in the past.  Default interface methods are intended to spare users from having to incorporate common implementations of certain interface methods; only unusual implementations need to be supplied.  Both static and default interface methods cause interfaces to act like abstract classes, with greater flexibility.

For JNBridgePro, the problem is that interfaces in most .NET languages (including C#) do not have these features, and attempting to map these features directly during proxy generation will cause exceptions to be thrown, or will cause DLLs to fail verification at run time.  In order to make these new Java 8 features available to .NET developers, we had to make some changes in the way that these new members of Java interfaces are mapped to their .NET proxies.

It was easy to determine how to map static interface methods. We’ve already had to deal with the problem with mapping static interface constants to proxied .NET interfaces, because most .NET languages don’t allow these, either.  For each proxied Java interface, we automatically create an associated helper class (called IConstants, when the original interface is I), which contains the static constants. Starting with JNBridgePro 7.2, static interface methods are also proxied into those same helper classes.

Handling default interface classes is a bit more involved. Not only are C# interfaces not permitted to include actual method implementations, “default” or not, but any C# class implementing an interface must account for every method in the interface, even if a Java class implementing the underlying interface doesn’t need to account for default interface methods.  This means that when we proxy a Java class that implements an interface with default methods, and that uses the default method, the proxied class will fail .NET verification because it doesn’t account for all methods in the implemented interface. To remedy this, starting with JNBridgePro 7.2 if a Java class relies on a default interface method and doesn’t actually provide an implementation of its own, then the .NET proxy will include an implementation of the method, which when called will result in a call to the default method. This should be transparent to the user.

JNBridgePro and Windows 8: It already works

We were at Microsoft’s Build conference in Anaheim a few weeks ago, where they unveiled their upcoming Windows 8 operating system.  In case you hadn’t caught the news, Windows 8 contains two distinct user experiences: a traditional “Desktop” experience which resembles Windows 7, and a new, touch-centric “Metro” experience.  The Desktop experience allows you to access the full .NET Framework as before; Metro applications run in a much more restricted runtime environment.

We’ve spent some time with Windows 8, and we’re happy to report that JNBridgePro, as it’s currently released, already works just fine with Windows 8 in desktop mode. So, if you’re already using JNBridgePro and want to move your application to Windows 8, or to create a new application for the Windows 8 desktop, JNBridgePro is as easy to use as always.

We’re also happy to report that the JNBridgePro plug-in for Visual Studio will work with the upcoming Visual Studio 11 Developer Preview with only minor changes, which will be incorporated in an upcoming JNBridgePro release.  This means that JNBridgePro will be ready for the new Visual Studio by the time VS 11 is released, and likely sooner.  In the meantime, if you want to use JNBridgePro in conjunction with VS 11 development, we recommend using the standalone proxy generation tool.  If you’d like to be a tester for the JNBridgePro plug-in for VS 11, please contact us.

As might be expected, Metro-style development, along with the more restrictive WinRT and new .NET Metro profile, offer a few challenges.  During the run-up to the Windows 8 release, we will be addressing those challenges.

We’d be interested to know whether any customers or prospective customers are planning to produce Metro apps, and whether they anticipate building .NET/Java interoperability into those applications.  If you are planning to produce such applications, we’d like to hear from you, and work with you, at this early stage in the Windows 8 product cycle — please contact us.

Over the coming months, we’ll periodically post new blog entries discussing interesting technical aspects of Metro and WinRT, as they affect interoperability.  We expect to learn a lot during this process, and we look forward to sharing it with you.

Java-in-.NET embedding and Java 7 and 8

Embedding Java components in .NET applications, when using Java 7 or 8, doesn’t work the same way it previously did with Java 5 or 6, as the focus handling has changed.

When Java components are embedded in .NET applications, and Java 7 or 8 is being used, focus-related events like keyboard events and mouse wheel events are no longer handled properly — they are no longer directed to the appropriate component, but rather are directed to the wrong place and dropped. (Other mouse events, including clicks, which are not focus-related, still function properly.)

Starting with Java 7, the Windows implementation of the AWT focus subsystem was changed.  Previously, every AWT and Swing component was mapped to an underlying Windows component (a “focus proxy”) that handled focus-related events and dispatched them to the appropriate AWT/Swing component. With Java 7 (and continuing into Java 8), the owning frame acts as the focus proxy for all components that are contained within it. Oracle claims that “the mechanism is transparent for a user,” but the change does dramatically affect the behavior of Java AWT and Swing components that are embedded inside Windows Forms and WPF applications. Our research indicates that the AWT focus subsystem is choosing the wrong Windows component as the focus proxy.

We are currently working on a fix to this problem, but we have no estimate on when that fix will be ready. In the meantime, if you are embedding Java components in .NET applications, we recommend using Java 6 for the moment. Note that if your embedded Java component does not depend on focus-related events (for example, it does not take text input or use keyboard shortcuts or respond to mouse wheel events), then you should be able to use Java 7 or 8.

Also note that embedding .NET UI components inside Java applications still works fine as before, whether Java 5, 6, 7, or 8 is being used.

We thank you for your patience while we work on this issue, and we apologize for the inconvenience.