ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

Using .NET libraries from JAVA is that possible?

Updated on May 2, 2013

Recent popularization of Web Services seems to solve almost any interoperability issue between JAVA and .NET systems due to platform independence and universal transport channel. And that is true, the flexibility and universality of Web Services based solutions in combination with well-defined standards makes this technology a winner in almost 80% maybe even 90% of cases. But really there are no cons?

Of course there are and cases unresolvable with web service pop out from time to time in many critical projects. The main reason why Web Services does not fit in each case is usually performance, maintenance and development costs. The decision how to solve these issues usually relies on system architects and it could be one of the most important decision in project entailing a lot of different consequences.

How to identify if your case should be solved with web services?

If you are the one to decide you should consider at least following points. Let’s say we have .NET library with some legacy business logic or critical encryption/trading algorithm or .NET only API to corporate CRM, here is how we could analyse this:

  • Check if your requirement is worth building dedicated client-server infrastructure. Will you need to run cross machine executions? Remember that web service is client server. In our case we would need to build web service on .NET side and wrap selected methods in our WCF SVC or ASMX interface. If it’s only one method and dll located on the same machine as our JAVA application is it worth to host web server and consume it on local host? Definitely not.
  • Check if you can afford it. Each web service call has quite big overhead on each request message if we use xml protocol each simple method is wrapped in xml envelope and passed in http request consuming web server resources, and including all other delays of transport channel, serialization/deserialization and web request processing in fact if it is trading algorithm that places transactions on forex or stock market we should avoid it… same in all other cases were we make a lot of requests in short time or we just count on speed we should not add that much of buzz into our communication.
  • Check if it’s not too simple. If the library that we use contains single method for encrypting or calculating something, should we make: web service, client, host web server, allow http communication, build .NET web project just to load one method from one dll and call it once in lifetime of our JAVA project? No.
  • Check if it’s not too complicated. Sometimes the amount of code that we want to reuse in JAVA could be oppositely too big. Wrapping thousands of methods in web service and passing thousands of execution places via web service client could cost us a lot in development and further maintenance. Simple example could be the case were we want to build JAVA application with WPF interface, I can’t imagine exposing all WPF framework classes via Web Services implementing call-backs and building out of it responsive UI.

We could assume that so far we have decided if our solution should and could be implemented with web services interoperability approach, but what should we do if it does not fit in there? Most of developers usually do not meet such problems but therefore if they do it’s hard to find a good solution. It is not that easy to get JAVA and .NET work together by our own, without spending for it more time than whole our project is planned for. And of course we should remember that it is not a good practice to reinvent the wheel.

What are the alternatives to use .NET libraries from JAVA application?

Most of us does not realize that there are some native JAVA to .NET bridges available on the market whereas these solutions does exactly this what web service does not so they fill our gap of 20% cases perfectly.

Native JAVA to .NET Bridge leverages JAVA native methods invocation capabilities with native platform specific communication channels and direct invocations on .NET objects. In this way we get .NET process being hosted natively for our JAVA application giving us access to any .NET library directly from JAVA code like they were native JAVA objects. Because of direct invocation passing between processes we get instant execution without delays, overhead and additional infrastructure.

Moreover we get several additional benefits, these are: efficient call-backs mechanism so we can easily subscribe cross platform events, access to any .NET library without any wrappers and implementation on .NET side, lifecycle of objects and processes bound into one runtime and no client server solutions therefore no additional side products to maintain and monitor.
JAVA to .NET interop market is not big. There are only few vendors who managed to deliver efficient and flexible enough solutions that could be reliable for projects of any size.

Choosing right bridge should be driven by simplicity of usage, performance and flexibility. This year there was new solution released called Javonet. It seems to be very attractive due to several reasons. The project was initially born as academic research for object database systems at Polish-Japanese Institute of Information Technology. From very beginnig it was aimed on high performance.

During commercialization it was enhanced with very programmer-friendly API and many useful features. Javonet gives access to any .NET library nevertheless it is custom-made, part of .NET framework or delivered by third party companies. There are no changes in .NET code required and libraries can be loaded from local directories or GAC. And it supports both x86 and x64.

Having access to any library instantly we can just reference them from our JAVA code and work on objects and classes from such library like they were native JAVA objects. Javonet API exposes special NObject variable for JAVA which works as handle to .NET object. Because all invocations and references are done in runtime we can initialize and utilize any object, method, property or field using reflection-style syntax by providing names in constant strings.

JAVA to .NET bridge like Javonet handles internally garbage collector actions and exceptions so we can catch .NET exceptions on JAVA side and if our NObject handle is collected on JAVA side corresponding object gets disposed on .NET side as well. All these features makes such bridging solution a huge cutting edge technology that delivers us all-in-one framework for using .NET code from JAVA.

The possibilities of these solutions are worth exploring as high performance and simple usage leads to new ideas of how we could apply this in our projects. In tutorial and samples we can read step by step guides how to make full JAVA application with WinForms or WPFinterface or how to extend .NET class in JAVA, sometimes even for highly experienced developers these kind of solutions looks like magic.

I highly encourage all JAVA developers to discover and test these solutions to keep in mind new alternatives how CLR and JVM interoperability issues could be resolved in modern world.

See how to call .NET methods from JAVA


    0 of 8192 characters used
    Post 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)