C++ Versus JEE

One C++ programmer's experience and impressions when moving to Java


June 21, 2007
URL:http://www.drdobbs.com/cpp/c-versus-jee/199905990

Stefan is a software developer in Berlin specializing in cross-platform development, user interfaces, and reengineering. He can be contacted at [email protected]


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.

Why Java

Java is successfull for two reasons:

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.

Why JEE?

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?

Why C++?

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:

Portability

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.

Control

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.

What's Missing?

The things you don't get in a single C++ shrink-wrapped box include:

However, thin and usable class libraries are available for most of these tasks. That said, it will cost you some coding to integrate, debug, and the like, and you'll not find all desired modules as readily packed as in a JEE application server. You won't, however, find a simple solution for clustering (with session replication). But in most cases you don't need it. An application layer load balancer will spread the jobs over a number of machines.

The Reality (Daily Life)

Based on my experience with the project mentioned at the beginning of this article, daily work on a JEE project differs from that in C++ projects. For C++ projects, the problems (in most cases) involved your own code. The problems to solve in JEE projects are more in the realm of configuration and maintenance of third-party modules. In retrospect we would have been better off to hire an experienced JEE administrator (although they can be hard to find).

Every component we used introduced its own (sometimes serious) problems: Eclipse with its numerous plug-ins did not work as expected, Struts required up to four files being changed if we modified a form page, and I am pretty sure that Hibernate introduced more problems than it solved.

Of course, there are poorly written C++ modules too.

Thesis: JEE is better suited for writing server applications.

Many mistakes can be avoided by the language, and much work is already done for you. Average programmers will make average mistakes. Thereby for an average and not highly demanding application, things like a garbage collector or prevention from pointers are an advantage.

Antithesis: C++ is better suited for writing server applications.

It gives you more control, more flexibility, and much more performance. Good developers will with ease take care of the problems of memory management, and they will be happy to manage pointers sometimes. C++ is not sophisticated, not simple, and there are deep pitfalls.

Synthesis

If you plan on large server applications that you expect will be used for a long time, you might be better of writing it in C++ if you have good C++ developers. For instance, consider Apache, written (of course) in C. In other cases, you might rather use JEE, but get a experienced administrator.

Conclusion

I still wonder why there are so few approaches for Web frameworks/toolkits or application servers written in C++. C++ is made for such a task. If you are in the situation of planning such a system, consider starting such a framework yourself. It might cost (much) more in the short term, at least until you have a working application. But in mid and long term, you (and maybe others too) will have many advantages. I think it will pay of.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.