Back in the beginning of October, I was dragged into the middle of a raging e-mail argument. The argument was whether J2EE was a success, and if it was too complicated. This was like waving a red cape in front of a Spanish bull. I felt then, as I feel now, compelled to respond.

Full disclosure: I am writing this as a member of JDJ's editorial board. However, I am an unabashed J2EE partisan, and I remain a Sun employee. While I no longer work on the Java platform, I am proud of the work my team did, and the work the current team is doing now, in defining and evangelizing the Java platform. I still believe that J2EE is the last best hope for freedom from tyranny in the enterprise software arena.

There are two key ideas underlying the Java platform in its entirety. First is the unwavering belief in "Write Once, Run Anywhere." This motivates everything we do on the Java platform. Sometimes, we do things that the community appreciates, such as making the specifications freely available on the Web. Sometimes, it motivates us to do necessary things that are less appreciated, such as creating a licensing architecture to ensure that if an application is written to the standard, it will run anywhere.

The second key idea behind the Java platform is fairness, both to software vendors and the community. This is one of the motivating factors behind the JCP. The JCP is a framework that attempts to ensure that all parties have a fair share in the decision-making process, and that the development of the technology meets the community's needs.

The process is imperfect, but rapidly evolving to address those imperfections. Like the old saying about democracy, it is a rotten system, but it's better than every other system that has been tried in the past. There are those who carp about the process, but they're usually the ones who don't succeed in their particular agenda. The process seeks to meet the needs of the community as a whole.

Two main criticisms are leveled at J2EE. First, it's too complicated. After looking at the specifications, this is a reasonable conclusion. Second, it's too hard to use. From a review of many sample applications, this is also a reasonable conclusion. However, both of these criticisms are misguided and specious.

From looking at the specifications, programmers can reasonably come to the conclusion that J2EE is too complicated. The main problem is that the specifications were not written for application developers. They were written for (and by) the systems software architects at the roughly 80 companies in the world that build enterprise-class transactional software.

It's important to understand that the specifications are written as part of the deliberative process required by the JCP. The specifications that result can be likened to legislation and sausage: the final products look and taste good, respectively, but you don't want to know what went into making them.

As a result of this process, the industry has adopted J2EE rapidly because it provides scalability, it helps integrate diverse applications, and it provides a consistent development API.

The second criticism has emerged as J2EE has expanded its developer base from the small group of highly skilled enterprise developers to a larger body of developers: J2EE is too hard to use.

The basic API of J2EE is what it is. It was our belief that tools vendors would build products that would ultimately make programming easier. The production of tools to simplify J2EE programming has been slower than we anticipated, but recent announcements from all the major systems vendors are encouraging.

In summary, let me be clear. J2EE is something unique in the short history of the computer industry. It's a technology developed cooperatively with an entire industry. It is one of the few times when a group got together, agreed on a direction, and built a billion-dollar industry in a few short years. The progress we've made is substantial, but we have much more work to do.