Bridging between JVM-based languages and .NET

Bridging is the answer to interoperability issues

Wayne Citrin
Suspension bridge image via Shutterstock


JVM is a platform for plenty of other JVM-based languages, many of which – such as Jython, Clojure, Groovy, Scala and Jruby – have a reasonably large developer community.

In general, these JVM-based languages allow a developer to write code that calls Java binaries – not a surprising news, since everything underneath is Java binaries running on the JVM, and it should all work together seamlessly. By using a technique called “bridging,” you can use the ability to call Java binaries to also call .NET-based binaries – that is, libraries written in .NET languages.

Bridging benefits explained

Bridging solutions transparently manage the communications between .NET classes that run on a CLR and Java classes which run on a JVM. Bridging’s advantages are countless. First, they are typically a lower-cost choice, as they allow the developer to continue to use the best components for the job, whether Java- or .NET-based. There’s no need to invest in additional components for compatibility’s sake.

Bridging also eliminates an increasingly common problem among developers: “developer fatigue”. Recoding from Java to .NET or vice versa typically requires massive time commitments – both in learning new languages and performing the actual recoding. Certainly, if you’re a .NET developer who must learn a new JVM-based language the task may be overwhelming. Bridging solutions allow the developer to start slowly by learning the basic structures and then leveraging existing .NET skills.

Bridging and proxies

The preferred bridging technique is to use “proxies”. In order to allow calls from .NET methods to Java methods, proxies that mimic the interfaces of the corresponding Java classes are created on the .NET platform. A .NET class can derive from a Java class by inheriting from the latter’s proxy, and vice versa.


A few examples

Let’s go through some examples which show how to access .NET code from JVM-based languages. We’ll provide brief excerpts here, with links to the full examples below. In all these examples, we’ll call a simple .NET library written in C#.

namespace DotNetLibrary
  public class HelloWorldFromDotNet
    private string theString = "";
    public HelloWorldFromDotNet()
      theString = "Hello World from .NET!";
    public HelloWorldFromDotNet(string s)
      theString = s;
    public string returnString()
      return theString;

We’ll show how to instantiate HelloWorldFromDotNet objects in a variety of JVM-based languages using each of the provided constructors, then call the returnString() method on each of the instantiated objects.



import DotNetLibrary
# bridge-mechanism-specific configuration code goes here
h = DotNetLibrary.HelloWorldFromDotNet()
print h.returnString()
h = DotNetLibrary.HelloWorldFromDotNet("Test String from DotNet")
print h.returnString()


Hello World from .NET!
Test String from DotNet

Similarly, one can do the following in Groovy.

import DotNetLibrary.HelloWorldFromDotNet
class SimpleTest {
  static main(args) {
    // bridge-mechanism-specific configuration code
    def helloWorldFromDotNet = new HelloWorldFromDotNet()
    println helloWorldFromDotNet.returnString()
    def helloWorldFromDotNet2 = new HelloWorldFromDotNet()
    println helloWorldFromDotNet.returnString("Test String from DotNet")

Here’s how it’s done in Clojure:

;; bridge-specific configuration code goes here
(def h1 (new DotNetLibrary.HelloWorldFromDotNet))
(.returnString h1)
(.returnString h2)



It’s also possible to call code written in JVM-based language from .NET. Some JVM-based languages, like Groovy, Clojure and Jython, run inside their own Java-based runtime environment, thus exposing a Java-based invocation API that’s ordinarily accessed from Java code. The logic behind it is to allow Java applications to call code written in one of these other languages. In such cases, the invocation APIs can be proxied into .NET, so similar calls can be made from .NET applications.

Other JVM-based languages compile their code into Java binaries. Bridging tools can generate .NET proxies from the Java binaries, and you can write .NET code that calls those proxies in the same way that the above examples do. The difference is that in this case the calls are from .NET to JVM-based language, instead of the other way round. In any case, details of how one can call from .NET code to code written in JVM-based languages are beyond the scope of this article.




Wayne Citrin


Inline Feedbacks
View all comments