11.1 Technology

By now, you probably understand that I believe technology is only a small part of any given problem. Java is not the best programming language that's ever existed, although it's easily among the most successful. The tools are not nearly as important as the hands that wield them. That said, technology does lead any discussion about the future of a dominant platform.

11.1.1 Less Is More

By far the biggest challenge Java developers face is the issue of complexity. I'm starting to see more advanced customers scale down by strategically stepping back from traditional J2EE application models such as EJB with CMP to simpler models such as simple POJO deployed on Tomcat. It's difficult to estimate how well lightweight containers are doing, but the early buzz and adoption rates are promising. The trend toward simplicity is likely to pick up momentum in other places. Hibernate is wildly successful not because it's more powerful than TopLink or EJB CMP, but because it's simpler. JUnit has been more successful than any other testing framework, by far.

The success of these types of frameworks must trouble larger vendors. The top web application server vendors, BEA, Sun, Oracle, and IBM, must take notice of the simplicity trend. They've got no choice, because their customers are struggling with J2EE. You can already see those vendors start to embrace simpler, lighter frameworks:

• Most vendors are not selling EJB solutions as strongly as they once were. Vendors are especially backing off of EJB CMP for persistence solutions.

• Many vendors are quietly developing alternative persistence strategies. Oracle has acquired TopLink, Sun and JBoss have included JDO solutions with their application servers, and IBM is now co-marketing another persistence solution.

• Vendors are working to build better, simplified tools for their communities. IBM has worked with the Eclipse project to simplify and replace their massive VisualAge product suite, and BEA is increasing their investments in Work Bench, which simplifies development of web services applications.

Still, there's a long way to go. The current web services specification is spinning out of control and closing in on permanent bloat-ware status. XML is getting so complicated and awkward that some researchers are already seeking an alternative.

11.1.2 Open Source

I'm not convinced that the future direction of the Java platform could or even should come from the major J2EE vendors. You can see the results of committee-driven big-enterprise design:

EJB

Vendors and customers alike spend too much time building on this dead-end technology.

Generics

The implementation of generics in Java 1.5 is a solution without a problem. The current implementation forces an interface and increases the burden of the programmer, for very little benefit.

Web services

Early versions of web services were light and simple. Later versions have patched a few holes and also dramatically increased the complexity.

Logging

Log4j is a fantastic open source solution, but Sun decided to go it alone, creating a competing and many say inferior implementation.

As I said in Chapter 1, the pressure for larger companies to build bloated software is sometimes too difficult to resist. Some of the juggernauts are starting to understand this. IBM, for example, is showing interest in open source software. They know that embracing open source software makes good business sense and can bring innovations to light that may not have surfaced in other ways.

The open source community fills an important niche in the Java community. It allows software to evolve and improve based on usage patterns of its customers. Many of the revolutionary ideas in the Java community have come from open source projects:

• MVC template technologies such as Struts changed the way we integrate user interfaces.

• JUnit changed the way we integrate and test software.

• Ant changed the way we build software

• Eclipse and Tomcat changed the way big vendors approach open source software.

• Hibernate changed the way we think about reflection and transparent persistence.

The next generation of open source software is already making waves. You've seen Spring, one of the lightweight containers that dramatically improves integration and assembly. Lucene is a clean text search engine opening up applications to searches that go beyond the database. Velocity, WebWorks, and Tea are user-interface technologies that are challenging the state of the art. These projects have the potential to change the way we code in dramatic ways. Beyond individual projects, open source software has another affect on the industry. True, open source software is not right for every customer, but Linux and the Apache web server both have the market share and industry backing to be long-term players. Figure 11-1 shows the typical components and services of an enterprise application. Corporate shops are conservative with their adoption of open source solutions. Still, penetration of open source software, shown in darker colors in Figure 11-1, is increasing. Already, conservative customers, including banks and insurance companies, are deploying open source operating systems and web servers in increasing numbers. In the past five years, Tomcat and JBoss have also made inroads. It's only natural that the line between what's acceptable open source and what's proprietary is always moving further up. I believe that it will continue to do so. In particular, databases and persistence are services ripe for open source deployment.

Figure 11-1. Open source penetration is increasing

I don't think it this trend will stop with the web server. While working at IBM, I never read one line of open source code, but that situation is changing quickly. For IBM, Eclipse is only the beginning. They are beginning to exert pressure on Sun to open up major pieces of the Java platform. They may not succeed, but it's hard to argue against the increasing roles that open source software can play. Oracle and BEA test their software for compatibility with key open source projects like Tomcat, and also generate Struts-compliant code.

11.1.3 Aspect-Oriented Programming (AOP)

Many a programmer has tried to design programming paradigms that make enterprise development easier. Object-oriented programming helps: you can make models with business rules that look and act much more like the real world. But OOP can only get you part of the way there.

Certain services called crosscutting concerns are difficult to add to an enterprise application because you need to apply them broadly, based on a changing policy. For example, many different objects might need to be persistent. You may want to add all methods to an audit log. You might also want a certain kind of method to participate in a transaction. You don't want to add this kind of service code to all of the classes in an application.

You've seen that object-oriented programmers tried to solve this problem with inheritance, interfaces, or programming models like containers. I've made a case that the best service implementation techniques preserve transparency with respect to the service.

AOP software is an attempt to make it easier to produce and consume far-reaching services (crosscutting concerns) while maintaining transparent models. Here's how it works:

• Break out core tasks, called concerns, from your requirements. The core concern is the business purpose of your application, such as making reservations in a reservation system. Other concerns (crosscutting concerns) should be separated from the requirements.

• Code individual aspects individually. This is where you'll notice the biggest productivity boost. You are free to think of each problem independently, allowing for better focus and better reuse.

• Configure the policy for each concern. Here, you specify how to identify the methods of your core concern and how to apply your concern.

• Your framework weaves the concerns together based on the configuration and implementation of each concern using a tool called a weaver.

That's the premise of AOP. Like most powerful ideas, it's remarkably simple. The details, though, can get tedious to implement Although some researchers and leading-edge developers are already using AOP, it's my belief that it will take a full-blown, successful aspect-oriented language to make the language thrive in the mainstream. We saw the same phenomenon with object technology in the early 1990s. It just takes time for the industry to move when it comes to major paradigms.

I do think that you'll start to see some aspect-oriented ideas quickly move into the mainstream well before AOP fully matures. In Chapter 8, you saw several AOP ideas in action in Spring's transaction management:

• Spring provides method interceptors to attach functionality to an existing method without changing the method.

• Spring provides a pointcut model to describe the methods that require a given concern, such as a transaction.

Other frameworks, such as JBoss, use core AOP ideas like method interceptors, and that's likely to continue. When enough developers use AOP ideas, it will be much easier for an aspect-oriented language to establish itself when the market conditions are right. Although you don't yet see AOP ideas in the mainstream, you do see several frameworks with an AOP flavor. The most common one is persistence.

11.1.4 Persistence

If you look closely at JDO, you can see several AOP ideas. Persistence is a crosscutting concern. JDO addresses it by implementing the concern independently of the core concern (your application). JDO then uses byte code enhancement to effectively intercept a Java thread of execution and inject calls to the JDO libraries—or, more generally, the persistence aspect. It's an effective solution. I've been impressed with the Kodo JDO product produced by SolarMetric. The performance, flexibility, and power of the framework is impressive, and big customers are starting to take notice. It warms my heart, because transparent persistence is important.

Nearly all enterprise applications have some persistence element. In some ways, the EJB CMP implementation has done us a disservice because it's made many gun-shy. The states of technology in persistence frameworks, RDBMS technology, and hardware have come far enough to make transparent persistence possible. While not all applications need persistence frameworks, many do. It's critically important for the Java community to establish an effective standard for transparent persistence. It looks like JDO 2.0 might be just what we need.

11.1.5 Containers

Most applications do not need EJB. It's just easier to build it all from scratch, adding in the occasional useful J2EE service as needed. I'll go even further: for the occasional application with true heavyweight enterprise requirements, there's a better way.

After reading Chapter 1 and Chapter 8, you know that I believe we're late in the era of the heavyweight J2EE container. They'll either wane or Java will die. They won't be killed by a technology so much as by an idea: that the idea of dependency injection has power. Right now, I've only coded minor applications in Spring, but after using Spring in the place of my J2EE container, I wondered what was missing.

Sooner or later, customers will notice that they're spending a lot of money without a lot of benefit. When that happens, vendors will respond. Whether they write their own or embrace open source containers doesn't make any difference. The idea of the lightweight container is what's important. The cat is out of the bag, and it will be tough to get it back in.