JCPP Project

Fri Apr 10 14:05:12 UTC 2015

The code is composed of several millions line of code.

  1. Rewriting everything in one shot is not possible, we would be forced
to stop evolving it and be only in maintenance mode (bug fixes)

  2. That means that the only way is to move parts of it. These parts
should be self descriptive, autonomous to form a module, to be moved to Java
      As we still have the other parts in C/C++, how can we interact with
the new part.
      Either using RPC in another process or in the same process using
JNI/JNA/FFI.
      The later was used during years and was not scalable:
          + hard to debugg when you have stacks that go both side C/Java.
Needs 2 IDEs, debuggers,...
          + error prone and when it crashed not easy to know why

      It makes sense when you have a JVM running 99% of the functionalities
and the remaining 1% developed in C/C++ are accessed via FFI.
      Not in my case where we have 99% of a process developed using C/C++
trying to have a very rich interaction (both direct calls) with the
remaining 1% developed in Java.

Also looked at QT and Objective C and decided to go in that direction for
the following reasons:

   + explicitly wanted to have an API very close to Java so that the move
from C/C++ to Java would be easy and automated

   + offer to the C/C++ developers same open sources that once could find
in Java

Hope it is clearer.

2015-04-10 16:14 GMT+03:00 Mario Torre <neugens.limasoftware at gmail.com>:

> 2015-04-10 14:48 GMT+02:00 Chacha Chacha <chachaparis at gmail.com>:
> > 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.
>
> Maybe I'm not following you, but you can very well replace portions of
> your application with Java and keep most of it running as native code,
> and John Rose gave you exactly the pointers needed to help out in this
> task (you can even start a virtual machine from a C application btw -
> this is so flexible that you could in theory even never write a line
> of java code and execute everything via JNI! [1])
>
> Now, a nice native API that maps 1-to-1 with Java maybe be nice to
> have, however there are valid alternatives that expose similar
> concepts, look at QT, or the Objective C libraries.
>
> Your project seems to be something like that, but as much as a nice
> and even interesting idea, I think it's entirely off-topic for Java.
>
> This is something perhaps more interesting from a Java perspective
> that you may want to look (and perhaps contribute!):
>
> http://openjdk.java.net/jeps/191
>
> Cheers,
> Mario
>
> [1] And yes, I've seen that too!! :S
>
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/
>