Stefan is a software developer in Berlin specializing in cross-platform development, user interfaces, and reengineering. He can be contacted at StefanWoe@gmail.com
Although I've been a C++ professional for 18 years, I recently faced the task of leading a team that had to build a large J2EE Web 2.0 application.
Of course, I've always been open minded towards Java -- especially J2EE -- and using the JBoss application server solved a lot of the work for free. But as the project proceeded, I saw that we didn't have fewer problems, just different ones.
Java is successfull for two reasons:
- Java's portability.
- Java's "idiot-proofness" (at least compared to C++).
Java comes with 100-percent portable libraries, including (as does C++) I/O, threads, and the like. Moreover, Java supports portable GUIs and more, and the language syntax is adopted from C++.
The main differences between Java and C++ are Java's lack of pointers and its garbage collector.
The downside is the introduction of a third-party -- the Java Virtual Machine (JVM) -- between your program and the operating system. This sounds good if you're planning on a simple application or if you need GUI portability. But it also introduces new problems, especially if you haven't installed the "right" JVM version, or haven't installed a JVM at all.
JEE, formerly known as "J2EE," offers services implemented in the Java language and runtime model. At the heart of JEE is an application server (or "servlet container") which takes care of redundant and standardized tasks that most server applications use -- session handling, persistence (which means database access), concurrency, and the like. This is good, of course, because once you've learned how to use the application server you can focus on the application. Additionally, standardized tasks in commonly available application servers should be more stable, and probably more flexible, than custom ones.
But there is a price you pay for all this. The more tasks you hand over to an externally supplied engine, the more difficulties emerge when solving problems. This might be okay if your application server is well supported and maintained, but such engines are often too large to trace down and resolve bugs on your own.
Moreover, application servers are often used in environments that have lots of users, generating heavy loads. Why use a computing and memory-intensive platform such as JEE for that?
C++ evolved from C. It is thin and deliveres high performance. It's more like a set of highly efficient (but sometimes dangerous) tools. If you know how to use it, you'll stay with it. If not, you'll be lost sooner than you might be with Java. In C++, you have to code much more by yourself than you do with JEE. Additionally, I've yet to find such things as application servers in C++, nor have I found many toolkits or libraries that would help build Web applications. (I wonder why?)
However, comparing C++ to JEE is somewhat unfair because you're really comparing a language to a complex server engine and runtime environment. Still though, we talk about two different paradigms that usually exclude each other and that do compete. But if you are comparing C++ to JEE, specifically in terms of Web or server applications, issues come up that didn't seem obvious to me before:
In general, server applications don't necessarily have to be portable. They will run on a specified OS and usually nobody will download and try server apps anonymously. But besides that, most modules needed for a server application are more or less portable (STL, posix API), or can be found in portable libraries (such as the Apache Runtime).
Performance and Memory Management
One of Java's big improvements (compared to C++) is its garbage collector. And the biggest problem with the JVM is its garbage collector. The garbage collector tends to sometimes halt your engine for seconds, and you sometimes might wish you could manage memory on your own. (I still wonder why Java does not give you the possibility to free resources explicitly. It would help.) And yes, Java needs huge amounts of memory. As long as your server application isn't a flop, you'll find that servers will be in short supply, although they can be added as needed. Still, larger servers are more expensive in acquisition and in power consumption.
The real pain, though, is the need to tell the JVM on startup how much and what memory to use. That's like running MacOS 7.
A C++ server application will typically contain proprietary source code, maybe some open source libraries (or files), and eventually you might use a framework. But the core will mostly be your source code, meaning that (more or less) all of it can be debugged.
On the other hand, a JEE application is a relatively small chunk of code (plus some configuration files and possibly JSPs), that lives within a application server which runs on a JVM. There are numerous parameters to adjust and the control resides more in the application server and JVM, than it does within your code. Again, application servers can be complex, and debugging server apps requires that you know a lot about the server you're using.
This still sounds good as long as everything is running fine. But as you know, software development consists mainly of solving problems -- and solving problems is easier in code that you (or your team) wrote. If you want to write a server application, you need control. Maybe even control about your failures. But you need control.