ULLINK is a Financial Software Provider For Connectivity and Trading solutions.

Very early in the development process we made the choice to build the client part of our software in C# and the server side part in Java. This choice was made to take the best of both Sun/Oracle and Microsoft technologies. At this time the key point was the interop between Java and C#, as financial software provider we need a robust, scalable and fast communication layer between client and server. IKVM is a part of this communication layer to expose POJO to .NET without traditional heavy and slow marshaling solutions.

IKVM is also used to share common libraries between Java and .NET, almost all our common libraries are developed in Java and then we use IKVM to generate .NET DLLs: "One code base, two worlds targeted".

We've used IKVM since 2008 and I can say without any doubt that IKVM is a ready-to-use solution for a company like ours that needs a reliable and scalable solution. With few clients in 2008, we now target more than thirty clients across the world! Thanks to IKVM. -- Laurent Barbisan, Software Architect at ULLINK.

IKVM on Tchatche.com

Yet another successful story using IKVM in a heavy-loaded production environment!

Index Multimedia is the editor of Tchatche.com website, a chat and social networking service handling not less than 7.5 million visits and 500 million page views each month.

Tchatche.com front-end is a .NET website, running on IIS, while the underlying chat engine is a stand-alone Java application.

Until recently, our web front-end was communicating with the chat engine through a Java client library, compiled with Microsoft's Visual J# Compiler.

Keeping our Java code compatible with this obsolete compiler was a real pain, and using J# was also preventing us from moving our C# code to .NET 4 Framework.

Reading all the good feedback about IKVM, we decided to take the leap!

Our web front-end is now talking to the Java engine through DLLs generated from our client jar files with ikvmc tool.

This allowed us to move our servers to .NET 4, and we now successfully manage 30,000 simultaneous connected users on our chat system.

We did not notice any negative impact on CPU or memory usage when we switched to IKVM. -- Frederic Borry, Project Manager at Index Multimedia.

IKVM at Modulus Capital

IKVM has been an invaluable tool for us. We've used IKVM since 2007 to integrate essential Java libraries with our native .NET codebase. Jeroen is one of the most talented and responsive developers I've ever come across. It is mind boggling that he has managed to produce a production quality, royalty free, open source product like IKVM. -- Brien Oberstein, Founder, Modulus Capital

IKVM at Deltix Lab, Inc.

At my company we are still amazed to see large part of our Java system successfully running on .NET platform thanks to IKVM.

We plan to use IKVM heavily in our technology stack. Our company develops a product for financial data integration and analytics. IKVM will be used to interface our Java-based server with C# based front end. IKVM allows to reuse Java code in .NET modules. For instance, the same ActiveMQ messaging code written on Java now also brings data to our C# application. -- Andy Malakov, System Architect, SCEA

IKVM at eTrading and Analytics Group at HSBC

eTrading and Analytics Group at HSBC provides real-time pricing and algorithmic strategies for a variety of financial markets.

We are very happy with IKVM. It enables us to develop our core libraries in Java and compile for use in .NET. The IKVM team is very responsive and knowledgeable about the issues we were facing.

Some challenges we faced were:
  - working with the classpath
  - downcasting generics in java to using a base object in .NET
  - integrating 3rd party C++ libraries which use JNI

IKVM provides a number of flexible options for us to define the classpath.

Generics would help us enforce the contract between the library and the .NET developer. In practice, we write thin .NET UI applications so this is manageable.

Integrating with in-house quantitative analytic libraries that are exposed through JNI worked effortlessly. However, we hit a roadblock trying to use Reuters sass3j.dll. We suspect there may be some differences in the event models.

All in all, this is an excellent tool that offers us the flexibility to focus on developing domain specific solutions without worrying about porting issues. IKVM solves that. -- Shamus Neville


JSTM is an open source Java library for distributed object replication. IKVM allowed us to replicate objects between java and dotnet applications very easily. The whole Java library is compiled to a dll, and communication between the Java and .NET processes is done over TCP or HTTP using the same Java code.

This project makes heavy use of the the Java IO and collections classes, and we did not have to modify the Java version to get the same features and similar performance on the .NET framework. There seem to be bugs left in the new Java 5 collections and for the formatting of dates, but the IO stack is robust. IKVM is way beyond our previous solution based on J#, and it allows lots of cool scenarios. -- Cyprien NOEL, http://jstm.sourceforge.net/

IKVM at Chordiant Software

Chordiant software and solutions help major brand enterprises around the world deliver the best possible customer experience.

Our product suite consists of J2EE applications as well as Windows desktop systems. As an IKVM customer, Chordiant was able to consolidate our dedicated C++ engine with our Java code base. This effectively enabled us to cut development time on one specific product in half.

Having used IKVM for over a year, we have found IKVM to work reliably and offer production quality operation. The one time where we did run into some specific problem, the open source nature of IKVM allowed us to quickly track down the bug and verify the cause of the problem. We had a fix for the problem the very same day.

In short, at Chordiant we like IKVM a lot. -- Otto Perdeck, development manager Chordiant Software

IKVM at eInstruction

At eInstruction, we provide classroom response systems that include custom hardware for gathering responses from students. Our main application was originally written in J++, including some pure Java libraries. This past year we needed to port to .NET. We made some attempts with J#, but ran into some limitations that IKVM does not suffer from. IKVM has been a key part of the success of our port, and we continue to use it to cross-compile our Java hardware API to .NET. IKVM is stable, performs great and Jeroen's support for the few esoteric cases we've run into has been fantastic. -- Chris Morris, eInstruction.

IKVM at WL | Delft Hydraulics

WL | Delft Hydraulics is an independent research institute and specialist consultancy based in the Netherlands. One of our tasks is to make world leading software in watermodelling. I work on the integration of different models. Some models may concern water movement, other models may provide information on water quality. All these models have to work together and exchange information. My main concern is the data communication between these models.

At this moment we're working on making our software OpenMI compliant. OpenMI is a European standard for inter model communication. The standard defines how, when and what information is exchanged between models.

In this part of our software different programming languages are used. The calculations in the models are done with FORTRAN 90. The communication between models is layered. The interprocess communication is implemented in Java. The OpenMI implementation, which takes care of the communication on model level is written in C#.

To make the connection between these communication layers we are using IKVM. A colleague informed me about the IKVM software. I read the documentation on the website, downloaded and started combining it with our software. It was an instant success. It solved a lot of our multi-language problems. We haven't stopped using it.

I have run into two problems. After updating our Java version to version 5.0, it didn't compile. It was easily fixed with assistance of the IKVM main developers. The second problem is trickier. In one of our test cases the Java code fails in the first call. This can be fixed by declaring a Java object in the main routine of the program. It can have something to do with threading in combination with initialization of static variables in the Java code. We have not figured out the problem yet. A drawback of IKVM is in this case that you can not debug the Java code to track down the problem.

IKVM saves us a lot of time setting up the connection between Java and C#. It can be a drawback when you have to debug the underlying Java code. It's amazing how this software bridges the gap between the Java and C# world. -- David Levelt, Software Engineer WL | Delft Hydraulics