Most Read This Week
Java at a Crossroads
A crisis of complexity, productivity, and standards
By: Steve Benfield
Mar. 29, 2004 12:00 AM
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.
Let's look at the first issue, complexity. There are several ways to look at complexity: the number of APIs, the number of methods in those APIs, the XML files needed to deploy a system, the level of abstraction of the APIs, and so on. A simplified way of looking at complexity is looking at the size of the specification itself, shown in Figure 1. At roughly 1,730 pages, the J2EE 1.4 specification is three times as large as J2EE 1.3. It has clearly grown in complexity as it encompasses Web services, EJB changes, XML, and so on.
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
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
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
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
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.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads