C++ Legacy Maintenance With JunC++ion
It is hard to believe that a vibrant programming language like C++ might be deemed "legacy" by some,
but it is true. The language is still being actively maintained and the new C++ standards together with libraries
like boost have done a lot to keep it attractive. Yet colleges have largely stopped teaching
C++ and we all know how hard it is to train up a good C++ developer.
If you regard your C++ application as a legacy application it is probably for one of the following reasons:
Your average C++ developer age is 50.
Your application consists of millions of lines of code and represents man-decades or even man-centuries of effort and investment.
You feel locked out of some exciting new technologies that are not available in C++.
All the other applications being developed in-house use Java or other newer languages.
The new enterprise backbone that your application should work with does not provide C++ APIs.
Rewriting the application in Java to gain access to most enterprise APIs is out of the question. Your application works and it is just too large for a complete rewrite. You really only see two options:
Gradually rewrite the application, module by module, over a very long timespan.
Develop integration APIs to communicate with other enterprise APIs to stay current.
While both approaches are technically feasible without using JunC++ion, neither is very attractive. You will simply spend too much time and money on developing integration code and too little on business logic.
JunC++ion does not magically solve all your problems, it just makes some integration tasks much easier and cheaper. When a task that was previously prohibitive because it required rare expertise, was highly error-prone, time-consuming and expensive — when that task all of a sudden becomes easy, reliable, fast and inexpensive, it is time to reassess your options.
Let's take a look at your two options.
Gradual Rewrite — Evolutionary Port
The gradual, modular rewrite is usually only an option if you have a nicely designed, modular C++ application. A modular C++ application allows you to treat a functional module as a black box that you can reimplement in a different language without disturbing the overall application too much. "Disturbing the overall application" is of course synonymous with "risk" and "high cost."
Needless to say that the average C++ legacy application is not generally highly modular. While the C++ code might be modular, it is usually modular at the type level. The C++ types are usually fairly tightly coupled, making it hard to come up with good module boundaries.
If you were to implement one or a few C++ types in Java, you would not gain much because the effort of bridging them back into the C++ application would be prohibitive and might even dwarf the Java development effort.
That changes completely when JunC++ion enters the picture. You can now easily and reliably expose the Java replacement types to C++. If you designed your Java API properly, the effort and cost of replacing the original C++ types with generated C++ proxy types becomes calculable and affordable. Instead of having to deal with the hard C++ to Java boundary, your integration problem becomes a C++ to C++ (proxy) shim problem that can be tackled much more easily.
Additionally, during the long time a gradual rewrite can take, you can implement new features in Java. Oftentimes during a rewrite, an application is frozen or put on "life support" (just critical bug fixes, no new features). After all, who wants to spend a lot of money on implementing a new feature in C++, knowing that it will be thrown away and reimplemented in Java? Just implement it in Java to begin with and then use it in your C++ application via the cheaply generated C++ proxy bindings.
We came up with the term "Evolutionary Port" for this use case. Rather than a stop-the-world effort that is so often doomed to fail or incur prohibitive cost overruns, this approach allows you to gradually replace C++ code with Java code. You might even be able to keep using the original test suite to make sure the application still works!
Following this process to its conclusion, you will end up with a small C++ skeleton invoking all the new Java modules. Your final step is to replace that skeleton with a new Java application skeleton and completely do away with C++. All along the way, JunC++ion just kept providing cheap, reliable integration code up to the point where it made itself redundant.
Develop Integration APIs To Stay Current
This is your other approach. Leave the C++ code as untouched as possible and just make sure that your application can still participate in the enterprise environment.
Organizations have to do that all the time and they hate it. API design is an architect level skill and an integration API should be ultra-reliable because everything else depends on it. This means you often have to schedule some of your top people to do something that does not give you any competitive benefit.
JunC++ion can allow you to quickly generate C++ APIs for external Java enterprise APIs that allow your old C++ application to become a first-class participant in your organization's enterprise infrastructure. You still have to integrate with third-party APIs, but now they're reliable C++ APIs and all of your C++ developers know how use these.
In this approach, you keep the application in C++ and just use JunC++ion to add Java into it. JunC++ion remains a part of your infrastructure until you dispose of the C++ application or the integration components.