Background

This software development group was handed a problem they had had no part in making: their company had acquired a start-up company for a product that provided complementary functions to their company's product set, including a strong web interface. The web interface was good news, now they would not have to develop their own. The bad news was that the web interface was in Java, but the data it had to access was in a database with tried-and-true access and retrieval mechanisms coded in a C++ library. Several other company products used the same data and the same C++ library. The software development group had to figure out how to provide database access to all the company's products, include the new one, so that all products could continue accessing the database for years to come.

The Problem

The software group had to get that web interface in Java talking to the C++ library so that it could access the database, and all without touching the C++ library.

The Problem At More Detail

The database stored data used by several company products. Its schema was updated on a regular basis to add, remove, and change the database tables. Several products in the company used the C++ library, which was tightly coupled to the Windows platform, to access, retrieve, and update data in the database. The C++ library could not be changed. It was working well and it provided efficient access to data for many products, including products that were not updated frequently.

The company's new product was written in Java and it provided a web-based solution that customers were demanding. It too had to access the database but there was no corresponding Java interface to the database.

The software group had to provide the Java product with access to the data in the database, using the C++ library without changing the C++ library at all.

The Solution

There weren't (and still aren't) many solutions for integrating Java and C++. For performance reasons, this group was forced to consider the Java Native Interface (JNI) to provide Java to C++ interoperation. Because JNI is a very low-level programming interface, coding in it is very complicated and error-prone, and requires special JNI expertise. There were no JNI experts in the group and no JNI experts readily available within the company. The software group had to hire a JNI expert.

Then the group evaluated JunC++ion. Although JunC++ion uses JNI to integrate Java and C++, programmers never deal with it directly. Instead, they write code at the object-oriented level and let the generated proxy types they use handle all the JNI details. After the evaluation, the project leader summarized the group's conclusion:

"JunC++ion is our JNI expert."

Though JunC++ion has the most obvious benefit when used to call Java from C++, it was still a good fit for the problem at hand. The team designed the desired Java database API. The Java API included lots of native methods that would then be implemented in terms of the existing C++ library. Using JunC++ion's special support for implementing native Java methods, the C++ programmers would be able to write code at the object-oriented level without ever worrying about JNI.

The Solution At More Detail

The software development group used a perl script to automatically generate the C++ library for accessing the database tables. The programmers updated the script to also generate a Java library, including many classes with native methods plus C++ implementations for the native methods. These implementations relied on the C++ database library and generated C++ proxy types for Java types.

They then imported the generated Java library into the JunC++ion code generator and let the tool figure out which proxy types needed to be generated. Over 1,700 types were generated and, together with the native method implementations, compiled into a native library.

The Java application could now use the generated Java API, which was implemented by a native library that used the original C++ database library and JunC++ion-generated proxy types.

Clearly, the development team had a lot of expertise at code generation. Why did they not simply generate the entire integration solution themselves?

The answer is that they would have had to expensively develop the same kind of JNI and Java/C++ type mapping expertise that Codemesh provided to them in an existing proven solution. JunC++ion provided a crucial "skill" that the team was lacking in cost-effective, reliable way.