J2EE and .NET are friends after all...

Java Developers Journal has an article entitled “J2EE + .NET, in which suggests that a number of organizations are combining J2EE and .NET, taking the best of the two worlds into creating new applications. This is about taking a look at the proper tool for the job and selecting the tool based on all the factors, not just what you know.

While I agree with a good portion of the article, one thing that really sticks out of the article (and perhaps I am just reading into it) is that Microsoft has revolutionized development environments by allowing all developers to be highly productive in the environment, suggesting that the “type in which ever language you prefer” is an advantage. This is not to say that it does not have any advantages, but one major issue that is sometimes overlooked here is that of maintenance of the code. While yes, it is great for the new intern to be completely productive in a non-mainstream language, such as Eiffel ENViSioN, this environment is not a “read in which ever language you prefer” and since code is read more than it is written, the choice of language is still an important issue for maintenance, such as for resolving bugs or to extend the existing functionality.

The other issue is how some of the languages supported are more-or-less coerced onto the CLI framework. An example of this was when I was talking about the C++/CLI extensions, but an even better article on the topic is Richard Grimes article in the November 2004 issue of C++ Users Journal, where he describes extensions for properties, events (delegates), interfaces, generics, and more, and I find these extensions even more disturbing than I did before. Take for example the following sample class from Listing 2 of the article:

ref class Person {
public:
  property String^ Name
  {
      String ^ get() { return name; }
      void set(String^ b) { name = n; }
  }
  property int Age;
private:
  String^ name;
};

While these constructs are extremely powerful and all, this is not C++, and even with using the preprocessor, it looks like it would be difficult to make this portable in any sense of the word. In order for C++ to be a first-class citizen in CLI and to allow the other languages to work with these assemblies, such changes will need to be throughout the code-base, thus making projects less portable to other platforms, not to fail to mention some initial investment in exposing your API to non-C++ languages. Portability was obviously not one of their aims.

As a few groups that I was talking to at OOPSLA regarding the gcnew changes said, when in Rome, do as the Romans. If you were targeting a .NET application, why would you really want to use C++ in it? Yes, there are some things that C++ can presently do that C# and other languages are not as well suited to do or that you have an investment in current C++ libraries, but developing full applications in C++ would not seem to be a natural fit. This is a similar synopsis that JavaWorld gave to J# a while ago.

I realize that Microsoft is attempting to target C++ for Systems Development, but C++ is already a very confusing language, and adding more confusion to it is not necessary. The effort to migrate all Java applications onto .NET and vice versa was not always a good decision, and the first article mentioned discusses how we can actually bridge the two technologies together. Bridging C++ into the .NET world would have had a vastly different feel than the present Visual Studio 2005 line-up, and as strange as Managed C++ was, at least it was mostly standard C++.