Home > c++, concurrency, java, soar > Why Java? … or … why not C++?

Why Java? … or … why not C++?

November 24th, 2008 Leave a comment Go to comments

In a recent meeting I was asked whether Java’s concurrency support was an advantage for jsoar over the existing C++ implementation. I kind of said yes, but was mostly incoherent because I’m always trying to avoid saying things that aren’t true.  This is probably a weakness. Anyway, I wrote the followup email below and I kind of liked it so I figured I’d post it … just for context, “kernel” here refers to the Soar kernel …

Regarding Java concurrency support vs. C/C++… In any discussion like this, you can argue than anything is possible in just about any language which is why I was a little hesitant to make a firm statement. In this case, C++ (or at least its runtime libraries) provide the same basic concurrency primitives as Java, i.e. locks, condition variables, etc. However, Java has two advantages here. First is cross-platform support. The Java concurrency and memory model are specifications that are implemented the same on every platform. So
while it’s possible to write a wrapper library that puts a common interface around say pthreads and the Win32 threading APIs, guaranteeing consistent semantics across both is notoriously difficult (e.g. http://www.cs.wustl.edu/~schmidt/win32-cv-1.html).

Boost and other libraries will cover many things, but you’re still left having to include the boost library and hoping that it plays nicely with whatever threading model any other library your using decides to use.

Furthermore, on top of the basic synchronization primitives, Java provides a really nice library of higher-level concurrency tools (http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/package-summary.html) like concurrent collections, thread-safe queues, thread pools, etc.  All of these can be implemented with pthreads, but it’s nice to have a standard set of tools that are used more or less uniformly throughout the community. The situation is similar to the mid-90s C++ where everybody and their grandma had their own implementation of a string class because a standard hadn’t yet been established.

More generally, since I’ve been thinking about this quite a bit lately for some reason, the advantages of Java over C/C++ boil down to the following:

  • Managed execution with garbage collection. I know Bob and Jon are dreading porting the new waterfall back to C where they’re going tohave to start reference counting symbols again
  • Far superior tools. Setting aside the complexity of C++ itself, as long as there’s a pre-processor, you’ll never have refactoring, or even browsing, tools that you can really trust. Not to mention accurate code completion, etc. This is where I personally see a 5-10x productivity gain over C++ and I consider myself a pretty knowledgeable C++ programmer.
  • More flexible run-time architecture. The fact that I can just add another main() to a code base for testing without creating another project is great, not to mention the ability to drop a library on the class path and load it reflectively. Of course, this can be done in C++ with DLLs, but with all of the requisite cross-platform baggage, not to mention issues with memory management when each DLL may have its own heap, compiler support for exceptions across DLL boundaries, binary compatibility issues, etc.
  • Superior testing tools. cppunit works, but again, because of the run-time stuff above, you write as much boilerplate as actual test code and integration with the development environment is limited.

The more I’ve thought about this, the cute stuff like scripting language support, running in Java application servers, and even concurrency falls away. They’re all nice, but also possible with the Soar’s SML Java (or C#, Python, etc) bindings (maybe with some tweaking).  So you’re left with the fact that development and testing on the kernel itself (and surrounding modules) is where Java really wins out.  If you want to do research on the kernel itself, it helps to not spend half of your time waiting for builds to finish, hunting through headers, or creating cross-platform wrappers for basic services.

Also, this isn’t really about Java. If jsoar was a completely personal project for me (i.e. I didn’t work at SoarTech), I’d probably try it in C#, which seems to be both mainstream (as opposed to other advanced
languages like F#, Scala, etc) and ahead of Java in cool language features. It’s more about productivity in C++ versus almost any other language out there.

Categories: c++, concurrency, java, soar Tags: ,
  1. No comments yet.
  1. No trackbacks yet.