It's been this morning in the underground.... I stood there, trying to look "somewhere". In this moment I started thinking about what I would have to do today. And instantly the fact hit my mind that I am currently doing something really nice. I am writing a program in Java. To be more precise: I am writing a set of Eclipse plug-ins. And while thinking about it another thought came to my mind: Only some weeks ago I was dealing exclusively with C++.
While reflecting about this shift I asked myself why so many people try to let one of these fantastic technologies appear better than the other. I think that it's the best choice to use only one - Java or C++ - if the use case demands it. In a lot of other cases I firmly believe that the combination of these two languages can yield very good results. That's why I decided to write a text which emphasizes some really interesting properties of both of them.
Why do I say this? It's because of the properties of these two languages and their environment. There are characteristics that are unique to either of them. And these characteristics make them the tools they are. On the following lines I want to point out some of them. When talking about Java I will narrow my considerations even more - to the Eclipse RCP platform. The properties I am going to talk about are on the C++ side templates and memory management and on the Java (RCP) side reflection and extension points.
Why these properties? It's important to me to point out that polymorphism is not only exhibited in the form of class hierarchies or interfaces. This is so-called bounded dynamic polimorphism. It says that entities need to expose one certain interface. Which kind of concrete type is responsible for implementing this interface is not important and hidden to the user. The other form - parametric polymorphism - is exposed using C++ templates. There it's not the interface that is written down, but it's done the other way round: The usage of a type is specified. This reveals (in the end) the same effect, but there is need for a base type any longer, which would limit the applicability of the abstraction that uses other abstractions this way. This is feature which is - even with generics - is not offered by the Java platform.
The reason for memory management is clear: This is one of those features of C++ which lets the programmer very strongly influence the performance of a C++ program (namely by correctly deciding when to allocate memory dynamically and - even more important - when not to do so). The possibility of the programmer to decide which memory is allocated by the runtime (and thus also released by the runtime) and which is not provides maximum control. In this context I would like to point out the importance of automatic variables. The hardcore Java-Coder could say that the GC of the Java runtime is much better because the programmer doesn't have to deal with this kind of low level stuff. In fact there are projects in the Java world going on which move quite into the other direction by also giving the Java programmer control over memory allocation and deallocation. This is because using the GC a great deal of predictability is disappearing. Nevertheless, the fine grained control over memory is a feature that is not matched by the Java platform and thus it complements it very nicely when both, C++ and Java are used together.
The choice of features on the Java side is a bit "belly-driven" because there I don't have too much of experience. Reflection is one of the magic things that let the Java platform expose information about itself. Even better: The Reflection API lets the programmer write code which accesses the program itself, queries information, loads components that are still not known and so on. This extremely dynamic type system even provides a way to cast objects of one type to another one (by using the Class.cast() method). One of the great advantages of this approach is that this runtime type information can be serialized and transfered anywhere. Thus reflection is a very important prerequisite for elegant independency of location.
Finally let me talk about the extension point mechanism (and the plug-in concept) provided by Eclipse RCP. These two concepts solve a big problem in software engineering, especially in the context of CBD (component based design). I am talking about a mechanism which allows a compoent to specify which parameters it takes and what the requirements on these parameters are. All this happens in a declarative way - namely by providing an XML descriptor (the file plugin.xml) - that contains all these information. It's interesting that a framework (one could also say a library) provides this kind of mechanism. In the C++ world I would consider it impossible that this approach would work. There mechanism like this would always be expected to be part of the language. (I think such thoughts are also the reason that there hasn't been made a big progress in the solution of this problem yet.) The extension point mechanism together and the plug-in concept on the other hand appear a good solution. On reason might be that they're very well integrated into the development environment (which actually is based on them). They become ubiquitous. Another very important point is that Eclipse plug-ins can specify which packages they export to other plug-ins. This has two advantages: The first is the very fine grained control over what is accessible and what is not and the second is that - even on binary level - a structure is preserved in the exported abstractions. This is not the case in a C++ environment where a "package structure" exists - in the best case - in the form of a directory structure on the disk during development time. During runtime no such structure exists anymore.
So, to draw a conclusion, I want to say that currently there isn't any language/platform which provides all of these features. And as long as this is not the case arguments which have the goal to invalidate either of these technologies should be considered erroneous. Finally, let me state that there are of course a lot of other properties of these two languages which are worth pointing out. In fact RCP and Eclipse are not even a part of the language, but they complement it in a very useful way.
