JCPP Project

[Jacob Wisor]

Hello Chacha,

Am 10.04.2015 um 14:48 schrieb Chacha Chacha:
> Hi John,
>
> The listed project solve the following problem: I am a Java developer, I
> need a C/C++ functionality that doesn't exist in Java how can I use it
>
> The problem that I am trying to solve is different and the following.
> Imagine a 30 years old financial software company. Initially it started
> with C development and few developers. With time and success, they got more
> market, more money, more developers, more millions of line of C code.
>
> In the early 2000, Java becomes a serious technology for the front end and
> the back end. So they decide to inject Java in their software, for the
> front end and some few multi-threaded servers.  Currently, 90% of their
> software is developed with C/C++ with 200 developers, and 10% developed
> with Java with few dozens developers.
> The majority of developers and management would like to use Java, but
> reality catches up.
>
> In that context, it is very hard to say just rewrite everything from
> scratch in Java.
> Several strategies were tried with little success:
>
>      1. In pure C/C++ process call through jni Java methods. Not scalable,
> hard to debug and maintain
>
>      2. Isolate some modules developed in C++ and redevelop them in Java
>       In that case, how process developed in Java and in C++ should call
> each other?
>       Using different kind of RPC technologies, different kind of protocols.
> None of tried solutions during the last decade was scalable and efficient
> enough (Corba, SOAP, WebServices, REST, ProtoBuf, ...)
>
>
> The bulk that is in C/C++ is forbidding them to have solutions where Java
> is involved and has a bigger place in the product.
>
> My approach was to say, among the C/C++ code, we can inject some Java
> related technologies and concepts that will allow the following:
>
>      1. C/C++ developers willing to move to Java will be happy to have that
> technology in their ecosystem as it is like Java
>
>      2. It is a step closer to shift everything to Java
>
>      3. Best way to implement interoperability between C/C++ and Java
>
>
> I understand that I am describing a special case where the legacy code is
> so important that it cant be redeveloped using Java.
> We don't encounter such thing every day, only in big companies maybe...
>
> It would be a pity if Oracle and the Java engineers don't take that into
> account at certain moment.
> Of course, tell me if something that I described is not clear.
>

I have come to usually ignoring such stuff by now but I cannot resist the urge 
to comment on this, simply because I have been through similar stuff.

All of this reads to me like you are trying to fix bad management decisions
with technology. The thing you are looking for is called JNI and there are good 
reasons for the way it has been designed. But actually, you are neither looking 
for JNI nor JCPP. You are looking for a master plan in your company to fully 
transition to Java. If your company has the resources to hire 200 C/C++ 
developers plus 10 Java developers, and obviously has the money and potential to 
do so, your management is apparently still not sure whether they want to make a 
move to Java or not. Unfortunately, most non-developers or non-geeks do not 
understand that Java is far more than just a programming language and what its 
true benefits are. It's a platform, an entire computing ecosystem. Another often 
inhibiting factor is the fact that companies start developing internal software 
without being aware of having partially become a software company too. Man, I 
have seen people really denying this although their service relied on thousands 
of lines of custom code.

In my experience, there does not exist code that cannot get reimplemented. When 
it comes to transitioning to a new technology 99% of the so called "problems" 
can be attributed to the fact that people just do not want to take the hard 
walk, they chose the quick and easy path. Indeed, the larger the company or code 
base that a service relies on the more rewarding is a clean cut afterwards, yes 
even when it costs a lot of money initially. I have experienced this myself 
first hand, in a company that already had a quite successful product with about 
a million lines of code. However, I must admit that they have been very eager to 
really make use of the benefits Java has to offer. Instead of just 
transitioning, they developed an entirely new Java-only product. And, they have 
become far more successful with the new product than they have even been or 
could have ever been with their old product. But, one major reason for their 
success is the fact that they have made a clear decision very early on not to 
bother with the legacy product anymore and redevelop the product in Java as 
quickly as possible.

My advice, especially with regards to (2.) is to keep on reimplementing modules 
or perhaps consolidating code pieces and functionality into new modules. Try not 
to bother about legacy support or as little as possible. Put all efforts into 
developing in Java. If a module seems to be lacking support for legacy code then 
you should start looking at it differently: It is not lacking anything, it 
simply is not ready for deployment yet and needs additional coding or other 
modules reimplemented. Adding support for legacy code in every new Java module 
is often just a waste of time, effort, and money. Just go with Java and be patient.

Regards,

Jacob