JCPP Project

[Tomasz Kowalczewski]

Maybe you can use in memory IPC provided by open source libraries such as
openhft.net? Or you can extract java microservices and use Aeron for low
latency communication (don't know what is the state of C++ implementation).

In both cases you can use SBE (
https://github.com/real-logic/simple-binary-encoding) for fast, allocation
free encoding (much faster than protobuf).

Cheers,
Tomasz

On Fri, Apr 10, 2015 at 3:14 PM, Mario Torre <neugens.limasoftware at gmail.com
> wrote:

> 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/
>



-- 
Tomasz Kowalczewski