Java and J2EE are at a crossroads - facing issues such as complexity and vendor lock-in. Where can you turn for the the productivity, performance, and ROI you've come to expect?

Having entered the mainstream and taken hold in roughly 70% of enterprises, Java is the clear winner when it comes to enterprise server architecture. As a unifying force for middleware API standardization and an aggregator of competition against Microsoft, it has also been a spectacular success.

Today Java faces several major issues, either real or perceived.

• Complexity: Java is perceived by most people to be very complex, too complex for developing certain types of applications.
• Development issues: Adoption by late majority developers and a shift from systems programmers to business developers.
• Lack of productivity: Microsoft is throwing around a lot of FUD (Fear, Uncertainty, and Doubt) and claiming that J2EE is inherently nonproductive.
• Increasing vendor lock-in: J2EE vendors are implementing proprietary frameworks that run only their own application servers.

A robust infrastructure for building enterprise applications in a portable, scalable, reliable, and secure way must be complex. So, yes, J2EE is complex - but by necessity. Microsoft .NET is also complex - it has many "standards" for enterprise applications and has thousands of methods available to developers. When people say .NET isn't as complex as J2EE, what they really mean is that .NET has a highly visual development environment, Visual Studio, that hides much of this complexity from developers. What Java has lacked a highly productive environment for building applications.

The Changing Face of Java Development
To this end, every major J2EE vendor is working on tooling that makes it easier to build J2EE applications. However, I suggest that these organizations are primarily building tools that make it easier to write lower-level J2EE code and are missing the needs of the fastest growing segment of the marketplace.

In a February 2004 report on the changing nature of the Java development community, Gartner Group reports that over the next few years, the majority of Java developers will be those who value productivity and ROI over technical purity of solutions. Historically the Java development community has been dominated by architects and experienced systems-level developers whose primary focus is in building a lasting infrastructure. The newer developers using Java are concerned with getting applications built quickly and easily - I call this group business developers. Table 1 shows some of the differences between these two groups.

The chorus of complaints about J2EE complexity has been growing steadily for the past few years. As more and more business developers join the ranks of Java developers, their frustration with a lack of highly productive environments emerge as attacks on J2EE complexity.

Tools Make the Productivity Difference
A double-edged sword in the Java world is its diversity of tools. There are many to choose from, each with a different focus and different area of strength. The proliferation of tools makes it harder for organizations to choose a tool and can lead to mismatches between the tool and developer skill and focus. Likewise, since no single tool dominates the Java market, it's easy for Microsoft to attack only J2EE itself - and not the individual tools.

BEA's WebLogic Workshop, IBM's WSAD, Eclipse, Compuware's OptimalJ, and ClearNova's ThinkCAP all address the problem of developer productivity and represent a productivity layer we call J2EZ. Each has a different approach geared toward different developer audiences.

The BEA and IBM products appeal to J2EE developers who want to make low-level J2EE coding easier; to use these products, a good bit of J2EE knowledge is still required. Since these environments only build code that runs on their individual application servers, this approach works if you've made the strategic decision to go with BEA or IBM to the exclusion of others - and you have sufficient J2EE developer resources available.

OptimalJ and IBM's Rational product lines are geared toward architects and designers who want a model-driven approach to the development of their applications - regardless of actual language choice. These require an up-front investment in the full analysis and design of the applications in question. The biggest payback is in the automation of building core business logic and business rules.

ClearNova's ThinkCAP appeals to organizations that desire a rapid time-to-market using business developer skills and J2EE programmer skills. The highest productivity comes in areas such as application flow, page development and design, data binding of visual elements to underlying relational or nonrelational data sources or objects - all the areas of an application that tend to be fluid and subject to rapid changes.

A common way of measuring the productivity of various tools and development environments is the Java Pet Store application. Originally built as a way to demonstrate various features of J2EE, it has turned into a way for vendors to demonstrate the productivity of their environments. Microsoft made a lot of noise in the marketplace last year trying to demonstrate the productivity of .NET over Java by showing that the Pet Store only took 4,410 lines of code in .NET versus 14,273 in J2EE. Microsoft's contention was that .NET was more productive than J2EE. The test was an invalid one because the original Pet Store had never been designed to minimize lines of code and was a way to demonstrate various J2EE best practices. Microsoft took the battle one step further and received third-party validation of .NET's productivity from the Middleware Company (owners of the popular TheServerSide.com Web site). My contention is that both .NET and J2EE are complex and that the only difference is in tooling. Given the right tools and frameworks, development effort can be drastically reduced. In our tests at ClearNova, we were able to build the Pet Store in under 500 lines of code (see Figure 2). However, had ThinkCAP been used to build pure middle-tier logic or an underlying Web services infrastructure, we would not have fared well at all because our tooling focuses on business applications. In that case OptimalJ or Rational tooling would have excelled. No single tool benefits all developers, and in the Java world, the diversity of tools means that organizations can match them to developer skills.

The Vendor Lock-in Myth
One major reason organizations go with J2EE is to avoid vendor lock-in. However, for most enterprises, there is clear lock-in with the servers and tools in question. For example, both IBM and BEA have productivity environments that require the use of their own application servers. Gartner believes that by the end of the decade, more than 40% of the APIs delivered by major application server vendors will be proprietary and only 60% will be pure J2EE compliant.

As the J2EE application server itself becomes more commoditized, vendors are looking for ways to differentiate themselves from alternatives and to provide barriers to customers who want to move to other servers. In the Java world, there is a process for introducing changes to J2EE called the Java Community Process (JCP). Currently there are more than 200 possible standards (JSRs) flowing (flowing slowly, that is) through the JCP. Major vendors such as IBM and BEA have begun to bypass the JCP and announce joint standards initiatives to get a competitive jump on possible competition and to drastically shorten the time needed to come up with the standards that will benefit customers.

The SQLization of J2EE
We've already seen this trend in the database market. In the early '90s a lot of attention was focused on ANSI Standard SQL and how each database implemented it. Developers were told to write only to the SQL standard and to avoid vendor-specific extensions. This attitude lasted for a few years but was abandoned as it became clearer and clearer that to really get performance from the database, proprietary extensions such as stored procedures, database triggers, and PL/SQL, etc., were needed. Today most developers couldn't tell you what the latest version of the SQL standard is.

The same thing is happening in the Java world. Over the next few years, as major J2EE vendors build proprietary APIs in and around their application servers, we will see the "J2EE" brand becoming less important. Changes will occur to J2EE, but they won't be drastic. J2EE will become a major part of the enterprise architecture solution, but it won't be the focal point that it is today.

Conclusion
J2EE and .NET are both very complex architectures - and they have to be. Tools and frameworks are what make the difference when it comes to productivity. There are a variety of tools and frameworks on the market, each suitable for different project types, developer skill sets, and levels of architectural control. According to Gartner, organizations will have to have at least two major tools for both the J2EE programmer and the business developer - and one size does not fit all. Focus on core J2EE and avoiding vendor lock-in at all costs is going away. Application server vendors are differentiating their products with proprietary APIs and features that extend J2EE. We saw this shift in the database world in the '90s and the focus in the J2EE world increasingly will be productivity, performance, and ROI with project and tool decisions driven by business necessity rather than architectural purity.