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.

This new version of J2EE is presented as the Web services version, so to be fair I should add SOAP, SAAJ, JAX-RPC, and JAXR to this list. In this age of integration, I wouldn't feel right if I didn't include JCA and JACC. I also feel obligated to at least mention the unfortunate specifications that were absent the day acronyms were handed out, like servlets, JavaMail, J2EE management, and J2EE deployment.

If this list of acronyms overwhelms you, I apologize. I do have a suggested course of action that will help you become educated in J2EE 1.4. 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, unless you're fortunate enough to be employed by a company that will let you sit and read specifications for a month straight (in which case, where do I apply for a job!).

We must ask ourselves what makes a technology successful. Looking back about 12 years, we saw the popular adoption of client/server technologies, and we saw business solutions implemented rather quickly. The kingpins of client/server were PowerBuilder and Visual Basic. I was fortunate enough at the time to be a Microsoft Certified Trainer and a Certified Power- Builder Instructor. In the course of about five years, I taught a little over 1,000 students, balanced with intermittent consulting engagements that kept my feet in the real world. While client/server had its weaknesses, I think we can reach a consensus that by and far PB and VB were successful at what they did. In fact, both technologies passed Wiseman's Law, which states:

A successful technology will saturate an 80% sampling of programmers only if 80% of the technology can be understood by those same programmers without forcing them to work beyond their regular work hours.

Rarely is there a discussion on the learning curve of a piece of technology. As a manager I'm responsible for a team of programmers and I must ensure that the team maintains a high degree of productivity. One weakness of Wiseman's Law is that it doesn't define any time frame for achieving the 80% milestone.

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. The problem, however, lies not with Java or J2EE, but with the way Java evolves through the Java Community Process. The formal goals of the JCP are found at www.jcp.org:

The Java Community Process is the way the Java platform evolves. It's an open organization of international Java developers and licensees whose charter is to develop and revise Java technology specifications, reference implementations, and technology compatibility kits.

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. If Java can't continue to entice new programmers while retaining the programmers it already has, how will our community survive?

The original premise behind a J2EE container was glorious: abstract multithreading issues, server memory management, wire protocols, etc., from the programmers and allow them to focus on implementing solutions, not server infrastructure. Somewhere during this journey the JCP has shifted from its solution-oriented roots to merely implementing specifications. This trend must be reversed for the sake of our community!

At present, the open-source community appears to be the only one focused on building solutions, but signs of strain are clearly evident among even the most popular projects. As a case in point, consider the Apache Axis project. Axis is an innovative next-generation Web services engine that, when completed, will transform a number of interrelated Web services specifications into a solution that can stand strong as one of the cornerstones in any enterprise-scale project. The most disconcerting aspect of Axis is that since its inception in late 2000, there has yet to be a production-quality integer release issued. In my opinion, this is due largely to the deluge of specifications the project must digest. Each time I visit the project's Web site, I'm amazed at how the acronyms are multiplying like rabbits.

To the vendors and active members of each of the ongoing JSRs, hear your constituents speak! We need a break from this explosion of TLAs (three-letter acronyms). We aren't interested in expanding our already voluminous library of specifications ­ we can't get our arms around what we have today. As a community, we must pay attention to the beleaguered JCP process and realign it with creating solutions, like those routinely released by the Apache Software Foundation.

By taking steps now, we are investing in the future of both Java and the community that grew up around Java. The entire JCP process must thematically reflect our desire to build solutions that simplify complex technologies for programmers. In fact, the JCP process should continue to use the JSR acronym, but with new meaning: Java Solution Request.