Anyone who regularly works with more than one development language and a third-party library has faced the situation described by: "Great library, if only I could have it in my programming language." Some vendors make a living from publishing different language versions of their product, but many can't afford or don't want to pay the costs of maintaining several parallel implementations of their product.

Consequently, over the years many integration approaches have been created to help us with the common problem of using software written in one language in another language. Microsoft has even gone as far as building language inter-operability into the core of its .NET platform (of course, they excluded Java). When talking about .NET, it should also be mentioned that a .NET-compatible language has to satisfy many constraints imposed by the .NET platform. So many constraints, in fact, that some people have said you don't really write your code in C++ or VB, but rather in a particular dialect of .NET. For anybody who is not using .NET, or who has to integrate .NET with .NET-foreign languages such as Java, here are the basic integration approaches:

1. Source code translation: Translate the Java source code of a library to C++.
2. Byte code/binary code translation: Take a compiled Java class file and compile it into object code. This, as well as the previous approach, can also be referred to as "implementation translation," because the method bodies are converted.
3. In-process wrapping: Create a C++ wrapper for a Java type that internally uses JNI to delegate from C++ to Java.
4. Out-of-process wrapping (remoting): Make a Java type available to a C++ programmer by calling from the C++ application into a Java process via sockets. This, as well as the previous approach, can also be referred to as "interface translation," because only the API signatures are converted.
5. RPC/Web services/messaging: This is really a special case of (4) and involves the sending of messages between applications written in different languages. SOAP, CORBA, XML RPC, etc., are examples of this integration approach.

Also, let's not forget that this type of integration problem does not start out with a portable interface description like CORBA's IDL or Web services' WSDL, but rather with a full, preexisting implementation in one of many possible technologies.

Let's take a quick look at some factors that influence our choice of integration technology before we delve into the more technical aspects. I haven't listed these points by importance; which points are important to you depends entirely on your specific integration project.

Granularity
At what level do we integrate? If we are dealing with a component API, i.e., an API that has relatively few integration points for relatively hefty operations, an RPC-based integration could be a good fit.

Performance
If we need fine-grained integration at the API level, any RPC-based solution is usually ruled out because we cross the language boundary too often for too little work, resulting in bad performance.

Reliability
Any out-of-process/RPC solution introduces new failure modes into an overall solution. Can you create a reliable integration solution for the specific API that you wish to use? If the answer is yes, how much more complicated is it going to be?

Security
Is an out-of-process/RPC solution without additional security mechanisms acceptable for your integration problem? Is additional security available and how much is it going to complicate the project or increase the price?

Scalability
In-process integration solutions usually have the best performance by far, but they may be wasteful in terms of system resources, and scalability might benefit from being able to distribute integration components. On the other hand, some APIs cannot be distributed/remoted without jeopardizing reliability.

Fidelity
How true to the original should the integration API be? Should it be self-evident to a user of the original API or are some special skills (like JNI, CORBA, or SOAP) required?

Purity
Is it necessary to completely remove the original technology from the picture (i.e., by translating/porting the code) or can we bridge between the two sides? Bridging might be the only feasible solution if you don't have access to all the referenced pieces (for example, a source code translator does not work if the code that needs to be translated references a third-party library for which you don't have the source code).

Licensing
This is often an issue for translation-based tools: even if you can translate your own code for an integration solution, do you have the necessary rights to translate referenced source code (for example, from a J2SE source distribution)?

Maintenance
Is your integration solution tied to a specific version of a technology and how easy is it to regenerate the integration solution and upgrade to a new version of the technology?

Clearly, given an API in one language, we would love to have the following: an automatically generated, highly reliable, totally secure, highly performing, true-to-the-original, semantically equivalent API in the other language. World peace would be another nice thing to have, while we're at it.

In the real world, of course, things are not that simple. I always like using Java and C++ as an example - first, because I know a lot about these two languages and, second, because they are deceptively similar. Many people think that it should be simple to translate an application written in one language into the other language. Let's take a closer look at this. The Java class in the following code will be our first example.

public class Person
{
  public String	name;
  public Person() { name = null; }
  public Person( Person p ) { name = p.name; }
  public String getName() { return name; }
  public void   setName( String n ) { name = n; }
  public static void  delete( Person p ) { PersonUtil.delete( p.name );
  public static Person create( String n ) { return new Person( n ); }
}

This is a fairly straightforward Java class. The only slightly unusual thing about it is its public data member called name. Maybe we were forced to make it public because we're using this type with a JavaSpace or we might simply have made it public due to a design oversight.