Java over-engineered?

I don't know the name of the author of this post, but he (or she) has some interesting observations. About two-thirds of the way down the post he has a list of things that are bad about J2EE - in comparison to .NET.
What I think is most interesting is that I think he is comparing typical solutions built on those technologies rather than J2EE and .NET. Ya I know - semantics.
Anyhow, he goes on to blame this on "cross-platform compromises" and "textbook OOP".

Hmmm.

In the many commercial grade J2EE code bases that I am familiar with (high volume web banking and brokerage web sites), I can't say that we have made many cross-platform compromises - very few in fact. But when we do, we usually encapsulate the dependency, and put a factory in front of it. This add layers and makes the code more opaque. That is certainly true. But, as I said, we don't do that very often. Would stored procedures made the code simpler? I don't think that would be true either. In our case, it would add another layer!

What about textbook OOP? Is that a bad thing? Must be. I am wondering if what is observed is a tendency to make things overly abstract, overly decoupled - perhaps even overly reusable? The motivation is good - planning for change. It is often done with a view to save money in the future, without looking at the ROI. I think that too often we spend two dollars today to save a dollar next year.

.NET does not have any redeeming features that will save it from the same fate - (except maybe an army of VB6 programmers who haven't seen an OOP textbook!). Given time it will build it's own empires. Perhaps with the help of Microsoft! Chris Anderson and Miguel de Icaza exchanged some volleys about the complexity of Avalon see here and here.