ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

Which JAVA bridge to go through?

Updated on June 1, 2015

Not so many developers have ever experienced an issue with interoperability. The interoperability by which I understand the problem of communicating two heterogeneous programming languages in one project. There are solutions that allow the developers to create the cross-platform applications. The example might be Mono open source solution that makes it possible to code in C# on any platform we would like to choose Linux, OS X, BSD or of course Windows. This is a great solution and solves a lot of programming problems, however not all of them.

Mono let’s you move from Windows to other platforms and code using .NET Framework and compile the code easily. This is fine if you are about to create a new apps, that you want to develop using C#, because your are familiar with this language or you see it as strategically best move. As Mono website says

“Built on the success of .Net, there are millions of developers that have experience building applications in C#. There are also tens of thousands of books, websites, tutorials, and example source code to help with any imaginable problem.”

Perfect and appealing. Also the fact that Mono is sponsored by Xamarin, which indeed solves a lot of interoperability issues is interesting as well. Xamarin is a fantastic product or solution (whatever it is more appropriate to call it).

What Xamarin brings to you is a possibility to code in C# for any mobile platform you would like to. I think this is an amazing creation of human mind. As they say on the website

“Anything you can do in Objective-C, Swift or Java, you can do in C#.”

How great does this sound? What is more is the fact that Xamarin provides you with the native UIs on every platform. They have created a designers for Android and iOS, so you can use Xamrin just like your native IDE. You have the full access to all the controls you might ever need as well as the access to all the functionality of the underlying platform.

But the question is, how to take any .NET dll and use it in a JAVA project?

Here I mean the scenario where you open your Eclipse IDE (or any other), you create a new project or open any existing project or library and out of a sudden, someone asks you to call a method from the little .NET .dll file that is provided by the 3rd party company in order to integrate with the particular solution.

And as any other Java developer you will think, allright JNI is my only free of charge solution and JNBridge is my very expensive solution. And this is perfectly fine. You go to the JNI’s Docs that is available on the Oracle’s website (here This goes quickly and smoothly, so you are quite encouraged. You have also heard this and that about JNI and somewhere on the StockOverflow some guy has written that thanks to JNI you will be able to use .dlls in Java projects.

Then the first line of the documentation starts to complicate things as it says that JNI (Java Native Interface) is a native programming interface that allows the running in Java Virtual Machine code to interoperate with apps and libs written in other programing languages such as C, C++. Hope is gone. It is gone because as long as you will try to load any C# dll (using JNI) from Java project you might expect anything but the success. In many cases there comes for example java.lang.UnsatisfiedLinkError. There are at least few threads on StackOverflow where this issue is explained and as not in every case, there are quite a few where the developers tried to call C# dll, not C++ dll and it turned out to be impossible.

So the problem is simple. You have a solution to call something from the provided .NET library, but you will need to do it using the native C++,C code. Sounds little complicated and time consuming? Correct it is just that.

You may have a look at this tutorial from Codeproject (, which contains a lot of word “idiot” but might be a good starting point. Here the author shows a simple example where he creates a Java program that will use C# code.

Don’t be surprised with the level of complication that this simple example is characterized with. I wouldn’t be surprised if you would feel little discouraged with what you would need in order to realize more complicated scenario. Especially the one with the provided .dll file that comes from the 3rd party.

Fortunately, there are options to the JNI. There are JAVA to .NET bridges available that you may use in order to address the issue with calling .NET dlls from JAVA projects. There is, a mentioned above, JNBridge that seems to be a nice product but little expensive. You can try the open source solutions i.e or the main JNBridge competitor javOnet that is cheaper and seems to be very easy to use. With bridges like javOnet which does not require any configuration and of course no C++ coding, or header files.

If you are looking for a quick and reliable solution for the problem of using .NET dlls from JAVA project and you definitely don’t want to get into JNI problems, the bridges would be a perfect idea. Let’s have a look at some simple examples. I have provided you with the tutorial from Codeproject which showed how to use JNI above. Now here you will find a nice example of javOnet use.

First the outstanding solution that javOnet has provided is the Live Lab system, which enables you to play around with the code and see how you can use javOnet in real examples. You can use the predefined code samples, modify them and compile everything on-line. You can see the immediate action. Visit the website to play around with it.

Coming back to the previous example of JNI. In order to invoke a .NET MessageBox from JAVA project using javOnet, what you would need is (attention!) one line of code (pasted below):

Javonet.getType("MessageBox").invoke("Show","Hello Javonet!");

In short, in order to achieve the above presented result, you will just need to add the reference to your javOnet.jar file in your JAVA project. This quick process will allow you to call any .NET Framework methods and load any .NET dlls.

In practice it would look like this:


I think that this one pretty much shows what is the general advantage of ready bridging solutions over the JNI manual invoking of C# code from JAVA.

Of course there is a bunch of other examples available on the javOnet website. This kind of bridging solution does not solely allow to use custom dlls. It is possible to use any method from the .NET framework you want.

Concluding it is much easier to use a ready bridging solution and it is recommended for the serious implementations where the highest reliability would be required. As you can see both JNBridge and javOnet have serious customers and this supports the fact that such solutions are worth pursuing in big projects. Also academic projects may benefit from ready to use bridges (i.e. javOnet has a special academic license which is free of charge). However if you still want to get into details and work it out yourself JNI would be the best idea.


Submit a Comment

No comments yet.


This website uses cookies

As a user in the EEA, your approval is needed on a few things. To provide a better website experience, uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at:

Show Details
HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
LoginThis is necessary to sign in to the HubPages Service.
Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
AkismetThis is used to detect comment spam. (Privacy Policy)
HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the or domains, for performance and efficiency reasons. (Privacy Policy)
Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
MavenThis supports the Maven widget and search functionality. (Privacy Policy)
Google AdSenseThis is an ad network. (Privacy Policy)
Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
Index ExchangeThis is an ad network. (Privacy Policy)
SovrnThis is an ad network. (Privacy Policy)
Facebook AdsThis is an ad network. (Privacy Policy)
Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
AppNexusThis is an ad network. (Privacy Policy)
OpenxThis is an ad network. (Privacy Policy)
Rubicon ProjectThis is an ad network. (Privacy Policy)
TripleLiftThis is an ad network. (Privacy Policy)
Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)