Peter Holditch, a Senior Systems Engineer over at Azul Systems, recently responded to a post I made which took issue with Java’s place within the financial technical landscape. Peter made some interesting points (which I’ll get to in a moment). However he also made some rebuttals to my post that I think are quite off the mark. Let’s tackle them first, and we’ll leave the parts about where we agree for last, so we can end on a shiney, happy note

Reading Benjamin’s article, I am guessing that he is rather attached to Microsoft technology (although he does mention C++ too) and thus is not overly keen on java, being from “the other side”. Never being particularly prone to bouts of technology religion (although, for full disclosure, I have been working on UNIX for 16 years, and java for 10) I read his assault on java with some degree of detachment.

I guess before we go on I should also make a full disclosure. I am a proponent of .NET in many instances these days, but I am definitely not technically religious. I have used Java on and off for roughly eight years, and at one point had one of those nifty Sun Java Programmer certifications. Yet conversely I also worked for Microsoft for a number of years and had all such Java knowledge wiped clean from my memory (just kidding). If I have any attachments to technology, its probably to standard C++ (on any platform) than it is to any modern managed language platform, but even there I am ready to concede that its technical power is often outweighed by its cost.

But let’s continue:

I did, however, feel moved to put finger to keyboard to try and move the debate on…

It seems to me that Benjamin is confusing 2 concepts, namely the language an application is implemented in, and the frameworks used to implement it…

For example, talking about writing GUI front-end applications Benjamin says:

“[java is] at a great disadvantage when it comes to front-end performance (graphics, painting, look and feel) when compared to native Win32 based libraries (MFC, VB, and more appropriately Windows Forms)”

It seems to me that this is not a typesafe comparison. The java language on the left of the comparison needs to be silently promoted to be compared meaningfully with the libraries on the right. He then goes on to say that since .NET front-ends are so nice and easy to build, the back-ends should be built in .NET too, to match.

Looking back at Yakov’s article, he is talking about frameworks too, not the language per-se…

“A couple of years ago I was participating in the design and development of a multitier and multiplatform equities trading system that was built around Java Messaging and Enterprise JavaBeans (both session and entity beans). This real-time system has successfully replaced a legacy C++ application”

What part of the java language are Enterprise JavaBeans, or Java Messaging? well… None. They are part of the J2EE specification; a specification of a runtime framework, not a language. And here is the point: Microsoft style development has a very rich and useful set of frameworks for building front-ends. J2EE (as opposed to the java language) defines a rich set of frameworks for server-side implementations. Hence, .NET style technologies get used on the front end (as Benjamin points out) and J2EE style technologies get used on the server side (as Yakov discusses, and Benjamin laments)

Well I guess I should apologize for not being more clear, when I talk about Java I most definitely am talking about the language in addition to its VM and libraries. I think Peter might be getting caught up in semantics though, I mean one of the very few places Java can be embraced completely separate from the VM and the Sun libraries is… wait for it… as a CLS compliant language that emits MSIL for the Microsoft .NET Common Language Runtime.

But that’s neither here nor there at the moment, because Peter was right, both I and Yakov were talking about frameworks and libraries, or in the all encompassing sense what I like to refer to as managed language platforms.

I would argue that’s as a result of CICS (and the other TP environments that support the language) providing such an overwhelming volume of useful server-side infrastructure that people just used the language, because the framework maximizes their productivity. Looking at C++, as a language it’s not a million miles from java, but it lacked infrastructure; memory management was a nightmare, and CORBA was always a rag-bag of distribution services, not a useful consolidated platform, such as CICS and J2EE provide. So the language withered, due to lack of infrastructure (whatever the “performance” that could be achieved - which opens up a whole new debate in itself; how do you measure “performance”, microseconds per calculation, or days to bring the finished system to market?)

I can’t argue with that (this Peter guy is very reasonable, I like him already). There’s no doubt in my mind that the ease of building systems with a powerful and cohesive suite of libraries offers delicious economical benefits, and that is true of any managed language platform, whether its Java or .NET. I should have been more clear about that up front. The crux of my contention however is that in high performance arenas I believe that a well crafted C++ solution will outperform one implemented in either managed language platform. And yet if the lure of the economical aspects of the managed world has you enchanted, then I would chose .NET over Java, for the reasons I originally laid out. If you forgot those, I’ll briefly review them:

1) On the desktop, the .NET CLR will always outperform the JVM. The CLR has intimate knowledge of the Win32 subsystem, including very tight wrappings around graphics and window message processing. Given that Windows is de facto on the Wall Street desktop, Java as a platform never stood a chance.

2) If you’re writing high performance trading platforms, they tend to have tight data and event type couplings between the GUI and the servers, which usually communicate using sockets (databases are just too slow to provide most real-time information on a trading system). Given this tight coupling, it makes little sense to use Java implement the server processing of such a system.

With that in mind, I think it’s important to point out that Peter was technically correct when he wrote the following, but the point was really out of context for the type of high performance systems we usually are faced with building in the financial world:

And here is the point: Microsoft style development has a very rich and useful set of frameworks for building front-ends. J2EE (as opposed to the java language) defines a rich set of frameworks for server-side implementations. Hence, .NET style technologies get used on the front end (as Benjamin points out) and J2EE style technologies get used on the server side (as Yakov discusses, and Benjamin laments)

J2EE really has never had a place in any system I’ve ever built for real-time trading. So I think I am on solid ground in lamenting the fact that Java is so popular for writing socket based server processes that talk to .NET based GUIs. Maybe Peter’s guilty of missing this point, or I may be guilty of not making this point clear enough, but now that it’s spelled out I would think this is a pretty difficult point to argue against.

Peter then makes a nice segue into his company’s own technology:

The fact that java is so prevalent, and has such a useful infrastructure underpinning it in the shape of J2EE, has driven adoption to the point where datacentres are groaning under the weight of servers needed to run the current production estate. The fact that the java virtual machine provides quite nicely for services like garbage collection and multithreading - capabilities harnessed in an orderly fashion by J2EE - means that the VM layer is ripe for technology optimisation [sic], to get better throughput - and better scale - for less power. Which is exactly the optimisation [sic] that Azul provides. Now, you don’t need one hundred parallel application servers, just a few extremely scalable instances side by side. Aren’t you glad your choice of java allows you to do that seamlessly!

I can’t argue with him here. I had a meeting with two very sharp engineers from Azul, it was about a year or so back. I was very impressed with the technology they have put together and I think you should quickly go to their site and investigate further if you are responsible for building high performance systems.

And lastly:

Oh… and Benjamin; Azul is designed to be able to support the CLR too… I’d hate for you to feel out in the cold

Hey, I told you this Peter guy was alright!