The future of J2EE

BEA's Tod Nielsen says Java has come to a fateful crossroads as it turns 8 years old.

4 min read
Thirteen years ago, 13 Sun Microsystems employees took on the daunting task of figuring out the "next wave of computing."

The question had certainly been asked before--but rarely has it been answered with an idea as revolutionary as the one this team would produce. Five years, and many thoughts, ideas and proposals later, the team introduced the world to Java technology--the first-ever community-created, enterprise-strength programming language.

Its timing could not have been more perfect; Java arrived just as another budding technology was taking root--the Internet. Few remember HotJava. It was the first browser that supported applets, small programs that were downloaded to the browser. These applets could turn static HTML pages into exciting applications such as interactive chess games, multiuser chat rooms or applications for stock trading. In time, Java became the gold standard on the server side; but it is its client-side lineage that gave it many of the key features, including security, portability and network awareness.

Those strengths matched to the needs of the Internet, and Java quickly became the de facto language for Internet and enterprise computing. It spread rapidly, changing computing and the way we live our Internet lives. Whether buying a book online, selling shares through an online broker or pulling cash out of an ATM--chances are, you're using Java.

But Java has come to a crossroads. As Java turns 8 years old, it's time to ask a similar question to the one that spurred its emergence: How will Java influence the next wave of computing?

While there are undoubtedly many viewpoints on the matter, one answer is certain: If Java is to increase its central role in computing, it must become easier. A key reason for Java's success in the enterprise has been the Java 2 Enterprise Edition, better known as J2EE.

J2EE is as powerful as any developer could ever dream. But with power comes complexity. All the J2EE specifications put side by side easily take a yard of shelf space. While I have a hard time visualizing enterprise technology becoming "easy" in my lifetime, it can--and should--be easier. If J2EE is to achieve mass adoption while maintaining what makes J2EE powerful, it must become easier.

How will Java influence the next wave of computing?
J2EE will either address this issue and increase its already central role in computing, or it will face the possibility of becoming the Latin of computer languages--a page in history, with little if any practical use. I don't believe the latter will happen; there are too many benefits and too many great minds behind J2EE. But it does need to overcome a couple roadblocks.

J2EE development remains incredibly complex, which keeps it out of the hands of everyone but the most skilled and expensive developers. Given the universal need for reducing costs and the current profile of most information technology developers, complexity can kill. What's more, the pace of commercializing J2EE innovation needs to accelerate in order for J2EE to meet customers' needs, stay ahead of competitive technologies and maintain its standardization.

In the same way the ease of VisualBasic unleashed Windows applications development, routine J2EE development tasks need to become less elite and more mainstream. The good news is we're getting there already. To automate repetitive J2EE procedures, tools are emerging that offer a visual framework for traditional corporate application developers to use J2EE, leaving more complex programming to the elite J2EE developers.

Making J2EE development less complex helps make it accessible to a large and entirely new set of developers--dramatically reducing overall development time, making better use of all development skill sets, and therefore saving enterprises significant amount of time and money.

The second roadblock--the speed at which J2EE innovations are made available to customers--is equally important to overcome. No matter how simple J2EE becomes, if it pursues a glacial pace of innovation, it will freeze itself out of the market. Someone somewhere will come up with something faster. Perhaps not better--but faster. And speed rules.

I believe that J2EE can still be the pacesetter, but it will take procedural changes by those who govern its standards. Through the Java Community Process (JCP), competitors take off their rival hats and, for the good of customers, hammer out standardized technology before bringing it to market.

If J2EE is to achieve mass adoption while maintaining what makes J2EE powerful, it must become easier.
This very important process takes time--often one to two years. Right now, we in the JCP standardize technologies first and implement later. In the meantime, customers' demands grow and vendors are forced to release what is seen as proprietary technology when in fact, it is technology released ahead of the standardization process. The Web itself provides us with a great precedent. It was in widespread use well before it was standardized by the World Wide Web Consortium (W3C). In much the same way, Web services were first released as part of commercial offerings and formally standardized afterwards.

This approach delivers standards proven to be useful to customers and delivers them much quicker than the current model. While J2EE wouldn't be where it is today without this rigorous process, we need to reorder the process: innovate, implement and then standardize.

J2EE has enjoyed some of the most successful eight years of any technology. With continued investments in reducing the complexity and accelerating innovation and standardization, I'm confident the next eight years will be even more successful.