Publish a .NET Version of Your Java API

In the previous use cases we talked about leveraging Java code in your .NET application, but many of our customers are actually developing products in Java. They have decided that offering a .NET integration API for their product gives them a competitive advantage.

Using JuggerNET, our customers generate .NET proxy types for their product and then usually an assembly for their customers to use. The .NET developers just add the supplied assembly and the JuggerNET runtime library to their application and they are good to go.

Now, to be fair, this approach is not for everyone. If you wish to have a pure .NET solution and you cannot have Java be a part of your solution, then this is not for you because at runtime the integrated product still requires a JVM and the Java types for which the .NET proxies were generated.

If you publish a Java product with a sizable API that your customers use, you can take any one of several approaches with respect to .NET:

• Port it to .NET and maintain a .NET version in addition to a Java version.

  Just say no. We have seen this before and it never ended well. The .NET version was never bug-compatible with the Java version, the only version where there was no feature lag between the two implementations was 1.0, the effort was usually abandoned after a few years because of cost and the few .NET customers were left stranded and angry.

• Don't worry about providing .NET bindings.

  This might be a legitimate option for you. Some Java products might not be able to compete in .NET or you decide that there is just not enough of a market to make it worth your while. If one of your customers really wants to do this, he can search the web, discover JuggerNET, and do the integration himself.

• Don't do it yourself but investigate and recommend JuggerNET to your customers.

  You always want to give your potential customer as few reasons to say "no" as possible. Being able to say: "We have tried this and it works. We can support you if you want to do this." can make a huge difference. All you need for this is a Starter Kit. It also helps to have a working relationship with us because then you can give us a heads-up before your customer approaches us and we know what to expect.

• You do it and you proudly use the availability of .NET bindings as a competitive edge.

  You can give your customers a working .NET integration solution that is always in sync with your Java product. Depending on your competitive position, you might charge your customer extra for the .NET API or you might use it as a distinguishing characteristic and give it away.

Which path is right for you depends on a lot of factors but we recommend that you make an educated choice and don't just ignore the question.