Great article with the biggest UNDERSTATEMENT of the year as it's title at Java Developer's Journal - "Is Complexity Hurting Java."  The article was pointed to me by my friend Edgar Sánchez...here's a small taste:

"EJB. JSP. JMS. JMX. JCA. JTA. JAAS. JAXP. JDBC. JNDI. This is a partial list of the acronyms you'll find in the 228-page J2EE v1.4 public draft. Of course, I was able to assemble this list of acronyms before I reached the bottom of page six."

And then it gets better:

"Each one of the aforementioned acronyms is a specification unto itself, so all you have to do is read each one, and you'll be set! Let's see here...the EJB 2.1 PFD specification is only 640 pages, so we can cover that on Monday and Tuesday. On Wednesday we can review the Servlet 2.4 PFD specification, which is a more palatable 307 pages. Then Thursday we can download and review the JSP 2.0 PFD specification ­ a mere 374 pages. Hmmm, maybe reading each of these in sequence isn't a solution either..."

And better:

"What is an acceptable time frame for a learning curve? Again, let's look at history. Both PB and VB offered a one week fast-track training course. A developer certainly wasn't ready to pass any certification tests after that one week. However, most students were fluent enough in the technology that after completing the course, assuming they used the technology on a daily basis at work, within three months they could be implementing business solutions. If we applied these same metrics to Java and J2EE, how would the technology rate? Right now, I believe the answer is very poorly."

And better:

"Specifications don't solve business problems ­ they solve technology problems. Companies expect their programming teams to solve business problems. Take any average Fortune 500 programming team with little or no Java experience ­ a team with a deadline to meet. Show them the number of specifications being released with J2EE 1.4. When you multiply that number by the complexity, size, and learning curve of each specification, I bet they become scared and want to reconsider the use of Java."

C# and Java: The Smart Distinctions. Article by Dominik Gruntz from Journal of Object Technology (Nov-Dec 2002 Issue), this article shows some of the subtle difference between C# and Java. [sellsbrothers.com: Windows Developer News]

This was a really interesting read...it really underscores the amount of thought IMHO that was put in to making C# better than Java.  They've really tried to offer the programmer a lot of power, even the power to shoot one in one's head.  Since a programming language syntax's primary goal is to allow me to clearly express my intentions, these are important changes.  If you look at Number 3, the changes to the try-finally behavior...you see than you can still shoot yourself, but they've removed the ambiguity.  Nothing sucks worse than to not really be sure if you intended to shoot yourself in the head...