Blog

Looking to the future

Our tenth anniversary festivities will soon be drawing to a close. Past installments on this blog have looked toward the past or the present, and now we’d like to spend a little bit of time thinking about the future.

Specifically, where do you think we should take JNBridge next? There are lots of scenarios where we can potentially apply JNBridgePro interoperability technologies, but we’d like to learn more about interoperability challenges you are facing, or new technologies that you might be using in the future that could present obstacles to interoperability. Here’s a list of technologies where we could conceivably extend the JNBridge footprint. Are these scenarios that might be of interest to you?

    • Metro and WinRT: Are you thinking about writing Metro or WinRT apps that need to call Java? How about Java apps that need to access Metro/WinRT DLLs or Portable Class Libraries?

 

    • Mono: Would you like to write Mono applications that call Java libraries, or Java applications that call .NET code running on Mono? Would the Mono be running on Windows, Linux, Mac OS X, or some other platform?

 

    • Mobility: There are lots of possible scenarios here:

 

      • Windows Phone 8: Are you considering writing WP8 apps that might call Java libraries? Would you want that Java to reside on a server, or on the phone?

 

      • Android: How about calling .NET libraries from Android’s Java? Or calling Java libraries from .NET/Mono running on Android?

 

      • iOS: Is there any kind of interoperability scenario involving iOS that you’re considering?

 

    • JVM-based dynamic languages: In a previous blog post, we talked about Groovy-to-.NET integration, and how it just works. Are there other interoperability scenarios involving dynamic languages that you’d like to see?

 

    • JavaScript and Node.js: JavaScript is a different platform than Java, but that doesn’t mean that there isn’t a place for JNBridgePro-style integration. Do you have any prospective projects involving integration between JavaScript or Node.js and .NET?

 

  • Additional Microsoft products: Our BizTalk adapter for JMS is very popular, but it’s not the only Microsoft product where JNBridge technologies could be used for interoperability. Are you thinking of integrating Java code with SharePoint? System Center Operations Manager? Visual Studio Tools for Office (VSTO)? Windows Azure?

The sky’s the limit: Any other interoperability scenarios you’d like to see us tackle? Please drop us a note, either to info@jnbridge.com or in the (moderated) comments below.

Groovy-to-.NET integration

Lately, much of the action in the Java world has been in the development and use of non-Java languages that run on the JVM. That’s why we were pleased to hear from a customer who wanted to use JNBridgePro to call .NET assemblies from code written in Groovy.

For those of you unaware, Groovy is a dynamic language that runs on the JVM. Groovy classes compile to Java binary .class files, and Groovy code can call (and be called from) any conventional Java class. In our customer’s case, they wanted to call .NET classes from Groovy, which really meant calling proxies. Since proxied .NET classes are just Java classes, everything should just work, and it did.

It’s really easy to illustrate how this is done. Let’s assume we have a very simple test class written in C#:

namespace GroovyTestDotNetSide
{
   public class SimpleObject
   {
      public SimpleObject(int i)
      {
         Console.WriteLine("In SimpleObject.ctor: value supplied is " + i);
      }
   }
}

First, we proxy it and generate a proxy jar file proxies.jar. Now, if we create a Groovy project and include proxies.jar in the build classpath, along with jnbcore.jar, bcel-5.1-jnbridge.jar (all of which would be included in any Java-to-.NET project using JNBridgePro), and groovy-all-1.7.5.jar (or something similar, depending on which version of Groovy is being used), we can write Groovy code to instantiate SimpleObject:

import GroovyTestDotNetSide.SimpleObject
import com.jnbridge.jnbcore.DotNetSide

class SimpleTest {

   static main(args) {

   // set up JNBridge
   DotNetSide.init(args[0])

   def simpleObject = new SimpleObject(3)

   println "Done!"
}
}

Just as in a conventional Java-to-.NET project, you need to initialize the Java side through a call to DotNetSide.init(), supplying the path to the Java-side properties file, or an equivalent Properties object. Once that is done, you can make any valid call to a proxy. In this case, we instantiate SimpleObject, but we can also call static or instance methods of SimpleObject, or access SimpleObject fields or properties or events.

Once the project is build, you will have a binary file SimpleTest.class, and you can run the application in the usual way (assuming all the jar, .class, and .properties files are in the current folder):

java -cp “proxies.jar;jnbcore.jar;bcel-5.1-jnbridge.jar;groovy-all-1.7.5.jar;. ” SimpleTest props.properties

The properties file can configure for tcp/binary, http/soap, or shared memory; if you are using tcp/binary or http/soap, you will or course need to run a properly configured .NET side.

As you can see, this just works in exactly the same way you’d expect if you were using Java.

While we have not yet tried it, interoperability with Groovy should also work in the .NET-to-Groovy direction. Similarly, JNBridgePro should also work when integrating .NET with other JVM-based languages like Scala, JRuby, and Jython.

Are you thinking about using JNBridgePro with JVM-based languages other than Java? If so, let us know in the comments or by sending us email at info@jnbridge.com.