JNBridge 3.1: Embed SWT/Swing in .NET and Winforms in Java

JNBridge 3.1 released yesterday, the latest version of the Java and .NET interoperability bridge tool that allows Java or .NET code to run in each others JVM or CLR in-process, with shared memory. Foreign code thus appears as native local ojbects. Version 3.1 adds the ability to embed AWT/SWT and Swing widgets inside WinForms apps, or embed .NET WinForms controls into Java UIs. Another new feature is the ability for Java code to call .NET code in multiple .NET CLRs even across a cluster.

InfoQ spoke to JNBridge CTO Wayne Citrin to learn more. Wayne explained technically how JNBridge's bridging technology works, specifically how to embed Java components into .NET (the reverse direction works similarly):

We create .NET proxy classes representing the Java GUI classes.  In the .NET code, calls to the proxies get directed transparently to underlying Java objects.  In our new version 3.1, we've created special wrapper classes that wrap the proxies for the Java components and make them look like .NET WinForms controls (that is, the wrapped class inherits from the WinForms UserControl class) so that they can be used wherever a WinForms control is expected.  The implementation of these wrapper classes is the key to achieving the embedding interoperability; they retrieve the Win32 window handles from the underlying Java classes, and manage them in the context of the WinForms application, making the Java components (or, rather, their Windows peers) children of the surrounding WinForms components.  That way, when the WinForms windows move or are minimized, the embedded Java components move or are minimized, too.

But why would one want to make cross-technology mixed UI components anyway? Wayne explained some of the usecases:

Clearly, if you're going to be embedding WinForms in a Java rich client, you're running in a Windows environment.  Deciding whether to embed a WinForms control in a Java rich client will depend on the tools you have at hand.  Many WinForms controls are closely coupled to the underlying Windows environment.  For example, the WinForms DataGrid control has integration with SQL Server data sources.  If you are operating in a Windows environment and you have such integrated controls, and you also have a Java-based client solution like IBM's WebSphere Everywhere Deployment, it may make sense to embed the WinForms controls inside the Java-based client.

For the case of embedding Swing inside WinForms, the sweet spot involves use of Swing custom controls.  Some users have created their own controls, and others have bought controls.  Up until now, those controls could only be used in the context of Java rich clients.  This meant that if users wanted to migrate to WinForms (because they preferred the programming model, or the development tools), they would either have to discard their investment in Java controls, or forego the migration and keep the investment in Java controls.  Now, users can keep the controls they've found useful, and at the same time migrate to WinForms if that seems appropriate.

Software vendors who offer Java controls can now also use our UI embedding capability to offer the controls to both .NET-based and Java-based customers.  As the market in .NET-based controls matures, we see .NET control vendors using our capabilities to offer their controls to Java-based customers, too.

JNBridge works with JDK 1.3.1+ and .NET 1.0+.  In-process communications as an interop mechanism is a high performant option for Java and .NET integration, and is one of many approaches, as described in Ted Neward's article Java and .NET, but why together?  See you can see more content about Java and .NET integration at InfoQ's Java + NET Integration Scenarios topic.