Libraries: Java vs. C and C++

Java is bloated. I hear it over and over. I hear it from colleagues; I hear it from C programmers, I hear it from C++ programmers. I hear it from Java programmers. I even hear it coming from my own lips (or typed from my own fingers), even though I generally like the Java programming language!

And, to be honest, the fact that Java is bloated is becoming increasingly irrelevant (though, to be honest, it's not always irrelevant -- sometimes you really do need all the performance you can muster and/or and the smallest executable you can achieve).

However, having been a software developer as long as I have, I can still remember the Assembly vs. C wars, and the C vs. C++ wars. The wars stay the same, only the names change: Now it's usually C++ vs. Java, with the C++ advocates on the side that always seems to lose.

With Great Bloat Comes Great Power!

One of the reasons Java is bloated is actually one of its greatest strengths: the standard Java library.

I had a (very brief) debate with someone on Usenet regarding libraries. He was trying to convince me that the fact that C came with a very spartan standard library wasn't a disadvantage. He felt it was advantageous: It keeps C small and agile, and gives you a lot of third party libraries to choose from, so you can be sure to choose the very best. I'll admit that there's some small truth to his argument, but the disadvantages outweigh the advantages in most application domains, as I'll attempt to show here.

When Will I Actually Get To Start Coding?

To complete any non-trivial application in C or C++, you need to involve a lot of libraries. You may end up needing GUI libraries, database libraries, scripting language libraries, arbitrary precision math libraries, collections libraries (this being more true of C than C++), networking libraries, security libraries... The list goes on and on.

In the world of C and C++ development, each of those libraries may, in turn, depend on other libraries. You pretty quickly end up in a hell of spaghetti dependencies. Just look at any non-trivial Linux application. The dependency tree on many of them will blow you away.

Of course, if you're being diligent, you'll want to evaluate multiple libraries in each category, right? You need a GUI? Okay, no problem: Do you use Qt? How about Gtk+? Have you considered wxWindows? Maybe FLTK? <Insert a dozen more GUI libraries here!>

Qt looks nice, but... Oops, your budget is small and Qt is expensive, really expensive. No problem, we'll use the free (GPL licensed) version of Qt. Oops, the onerous restrictions of the GPL doesn't meet the requirements of your company? That's a shame. Let's try Gtk+.

Oh dear, the latest version of Gtk+ has a security advisory out against it? Wait, it's not the Gtk+ library itself, but a library the Gtk+ library itself depends on? Better keep track of all those dependencies...

Bah, let's try wxWindows. Happy days, it looks like the wxWindows library will meet your needs!

Aw, darn it. wxWindows doesn't support all the platforms you're targeting. Back to the drawing board.

Now repeat this exercise for the dozen or more libraries your application may require. Good luck finding some time to actually, you know, start coding your own application. (And, yes, I'm exaggerating a little bit to make my point. Sue me.)

Java, on the other hand, comes standard with Swing for your GUI; JDBC for your database connectivity (or even Dirby if you need a lightweight database); a JavaScript interpreter for scripting (Rhino); arbitrary precision math APIs, collections APIs; networking APIs; security APIs; etc.

All of a sudden, the burden of evaluating libraries, researching licensing issues, tracking dependencies, ensuring platform support, and keeping abreast of security vulnerabilities has dropped to zero. You work has been reduced to making sure an appropriate Java Runtime Environment is installed.

Every developer probably already knows this, but Sun also offers Java with an extremely generous license (free as in beer). This includes the development kit and the runtime environment.

Starting with Java 7, Sun even plans to release Java under a license that should make most Free Software advocates happy. There won't be any barriers to anyone shipping Java with their operating system, whether it be Windows, MacOS X, Linux, BSD, etc.

Conclusions

In any case, I hope I've made my point. The rather spartan standard libraries that come with C and C++ are a huge disadvantage in many application domains, putting a much greater burden on the developer. I'm convinced C and C++ still have their place and will still be in active use decades from now, but a huge number of applications are better built on higher level languages with massive (read: bloated) standard libraries.

Go Bloat!