Revisiting the .NET - J2EE Debate

Share on LinkedIn9Tweet about this on TwitterShare on Google+0Share on Facebook0

Guest Post by Jason Carter

There was recently a discussion on one of our internal forums on the relative merits of the .NET and J2EE platforms for enterprise applications. The subject generated a lot of interest since a lot of the readily available comparisons are nearly a decade old. J2EE supporters tout its ability to scale vertically, integrate more naturally with legacy systems, its backward compatibility and platform independence. .NET evangelists referenced a superior IDE, shorter development cycles and horizontal scalability.

In the last decade, most of these arguments have become harder and harder to defend under pointed scrutiny. It’s almost becoming an emacs vs. vi style debate. If you allow that many of the older arguments for or against a platform no longer hold the debate becomes pretty straightforward.

Music as a Metaphor

You probably remember Bach’s Toccata and Fugue in D minor from the 1940 Disney movie Fantasia, a piece originally composed for the organ. Imagine you were asked to arrange for a performance of Bach’s Fugue and were directed to do so with a piano or a violin.

If you think like I do, the first question you would ask is do I know any piano or violin players? (i.e., do I have Java or VB/C# developers?) If I do not, I might ask: which one is cheaper to hire? Pretend that there’s only one piano manufacturer in existence and the metaphor is pretty apt.

The point is that the majority of other arguments are going to be very difficult and tend to fall apart on pointed scrutiny. Oftentimes the argument is settled by an empowered individual preferring the piano to the violin.

This is the nature of the .NET vs. J2EE argument in 2010:

I can play Bach’s composition on either the piano or violin. There will be subtle differences, but the piece executes similarly on either platform.

Two more points to complete the metaphor.

If I have a lousy piece of music full of discordant harmonies etc., no piano or violin is going to make it sound good. The platform can’t hide bad code.

In his recent keynote titled “Public Static Void” at O’Reilly’s OSCON, Rob Pike (a distinguished Google software engineer) took so-called industrial programming platforms to task. He claimed that the languages have become “hard to use”, “bureaucratic” and “subtle, intricate and verbose”. He argues that the existing models are “oversold” and not designed to solve every problem that they are currently over-extending to accommodate. These “grafted” on patterns or modules are evidence of a failure or shortcoming in the fundamental platform.

Pike then goes on to evangelize Google’s new Go platform and it will be very, very interesting to see how that matures. In the meantime, corporations should be paying close attention to the modernized LAMP stack employed by companies like Facebook (a combination of open platforms like Linux, Apache, mySQL and PHP now augmented by things like Memcached, Scribe, Hive and Hadoop). This is equivalent to arranging Bach’s piece for a brass quintet.

Far superior, no? Nimble, open technologies working in concert - often are the best platform. Especially for enterprises demanding an agile, low cost, flexible and scalable solution - and who isn’t?.

Bottom line is pick the platform based on availability of skills but don’t ignore the emerging open stacks, many based on LAMP components.

cc licensed flickr photo shared by celesteh

Share on LinkedIn9Tweet about this on TwitterShare on Google+0Share on Facebook0
  • I really appreciate your post and you explain each and every point very well.Thanks for sharing this information.And I’ll love to read your next post too.