Last night I had the pleasure of presenting a sneak preview of the soon-to-be-released Coherence 3.4 at the UK Coherence SIG. While it’s been some time since we’ve seen a new release of Coherence, based on what’s currently in Coherence 3.4, I can certainly see why!
Although we’ve not yet produced a Release Candidate (coming very soon I hear), I was fortunate enough to get a build earlier in the week and run it through it’s paces. So far so good. All of my regular projects (and POCs) work as expected, even the one’s where I’ve customized core components – which is a great first step for any release!
The big ticket item for me though is C++. It’s not so much that I want to go back to developing with C++ (I’m pretty comfortable with Java at the moment), it’s more that we’ll soon be able to satisfy a lot of very patient organizations. Given what I’ve seen I’m sure they’ll be a). very happy the wait is almost over and b). very happy with the results.
[Ok... there are a bunch of other very cool and extremely useful Java & .NET features in Coherence 3.4, but for now I'm going to focus on C++. I'll talk about the other stuff in a later post ;) ].
Probably the biggest thing about Coherence C++ for me at the moment is not necessarily what it does (we all expect it to work), but it’s what we didn’t do that will count in the long run. Unlike most approaches to C++ <-> Java integrations I’ve seen, the Coherence Engineering team has maintained the philosophy that “if it’s meant to be in language X, then we’ll write it in language X”. What does this mean? Simple really. Coherence C++ is just that – it’s written in pure C++ (using STL)… well so far.
So… It’s not a C++ wrapper around the Java or .NET version of Coherence. Nor is it a solution where you have to embed a Java Virtual Machine inside your C++ processes or embed your C++ applications inside a JVM. Additionally you don’t need to write JNI code (and we haven’t either). It’s a pure C++ Data Grid client implementation that talks directly with the Data Grid using our POF (Portable Object Format). It uses wirelevel packed byte binary communication – no wrapped XML objects etc. As requested, it’s “as close to the metal” as you can basically get.
Like Java, it works across platforms and operating systems. That is, it’s designed to run on the usual suspects, Linux x86 32bit and 64 bit, Windows 32bit and 64 bit, Solaris etc. And… it also manages memory itself (more on this in the future).
Why did we go to so much trouble doing this when we could have easily used a third-party “wrapper” around either of our Java or .NET Coherence implementations? We figured if you’ve invested in writing C++ to produce high-performance applications, so should we.
[updated] Here’s what some simple code looks like :)
//get a named cache (just like Java)
NamedCache::Handle namedCache = CacheFactory::getCache(“remote”);
//insert/update a value in the cache
Object::Holder prev = namedCache.put(“message”, “gudday”);
//get the current value from a cache
String::Holder curr = handle_cast<String>(namedCache.get(“message”));