Beyond Java/Crown Jewels

From WikiContent

< Beyond Java
Revision as of 17:12, 17 March 2008 by Docbook2Wiki (Talk)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search
Beyond Java

After the sixth drop in 40 minutes, I looked back up the river, and reflected. I was colder than I'd ever been. I hadn't eaten in six hours. My head and back hurt, and I was afraid—in short, pure bliss. Despite the painfully long hikes with a boat cutting into my shoulder, and the fear of facing a wall of water barely covering rocks that have maimed or even killed before, and the ubiquitous smell of wet neoprene every evening, I can't get enough. Kayaking delivers me to places that nothing else can reach. The immediate feedback tells me exactly how I'm doing. Others can't do it for me, but others can tell me how to do it for myself. And the feeling of conquering a tiny piece of river is incredible.

Java was once like that for me. I get enormous productivity jolts out of Java's incredible community, and countless open source projects. The open standards and the JVM mean that my knowledge, and my applications, can move from place to place. Java's been tremendously successful. You've seen my views about why it was popular. If you're to understand what might possibly come after Java, you need to ask questions about Java's continued success:

  • What makes Java hip, and draw such a wide variety of people?
  • How has the open source community thrived, in times, despite Sun and the power vendors?
  • What are the indispensable technical underpinnings that make Java successful?
  • What makes Java so adaptable that programmers can build everything from web sites to databases?

Answers to these questions go well beyond one single brain. To provide a better answer, I interviewed dozens of the top Java developers and asked them what made Java so successful. Table 3-1 shows some of the interesting answers.

Table 3-1. Reasons for Java's success according to top Java consultants

Consultant Why was Java so successful?
James Duncan Davidson I think it comes down to the fact that server-side programming in Perl and the like was inefficient; server-side programming in C and C++ was hard. Java and servlets in particular busted open a door for Java where it could really take root.
Jason Hunter It allowed you to do something that couldn't be done in any other way, and that was applets. Applets in and of themselves didn't end up as an important technology, but they provided Java with a protective beachhead where it could initially establish itself without any serious competitors.
Dennis Sosnoski Java has a well-designed language and runtime environment. Prior to 1.5, it also had the advantage of being relatively clean and easy to teach.
Stuart Halloway It was better than C++.
Richard Monson-Haefel Java is a great static object-oriented programming language. It's portable and has loads of APIs, products, and open source projects. It is a well-designed language and virtual machine. Initially, it was a very progressive and well-timed language design. Also, portability was big. Today, it's simply everywhere, which is why it continues to grow in popularity.
Ramnivas Laddad Java allowed a widespread and mainstream acceptance of garbage collection and reflection. Although these concepts existed forever, mainstream developers didn't really use them until Java. Also, Java achieved platform independence to a reasonable level.


Now, you can start to see a clearer picture. From the answers in Table 3-1, several threads emerge:

  • The technical bar for success was not too high. Since so many were developing business applications in C++, which is a systems language, Java needed only to improve on that experience to succeed.
  • The ability to develop enterprise applications was critical. James Duncan Davidson suggests that the central enterprise problem of the time was enabling for the Internet.
  • The technical underpinnings of the language, especially the JVM, represented a significant step forward.
  • The importance of community represents a significant achievement of Java.
  • Applets may have been the killer app that launched Java.

If you compare these comments in 2005 to similar comments made in 1997, you see a few notable differences: Java's exception strategy and static typing may be a hindrance rather than a help; Java's productivity may no longer be as good as it once was; Java has had a bigger impact on the server than on the client; and Java is not as simple as it once was. Still, Java experts remain remarkably consistent in terms of the importance of the JVM, community, Internet development, and improvements over C++.

Contents

Language and JVM Design

In 1996, the JVM represented a significant departure from traditional thinking. Overwhelmingly, organizations exclusively used high-performance compiled languages on the server side. Developers patched on security instead of baking it in from the beginning. And vendors attempted to achieve portability by building extensive libraries at a very high level. Instead of driving on this well-traveled road, they reached for the steering wheel with both hands and threw all of their momentum to the side, swerving aggressively into unpaved, uncharted territory.

Portability

In the early and mid-1990s, many in the industry were just starting to think about portability. In particular, I vividly remember working on object-oriented technologies at IBM. The project, called System Object Model (SOM) , emerged from a research project that formed the foundation for OS/2's groundbreaking object-oriented desktop, and some experimental technologies that never made it out of the lab. The goals of SOM were ambitious: we wanted to build a common object model underneath as many object-oriented languages as possible. Then, we could develop a common suite of libraries that developers could use across languages and operating systems. Over time, we discovered the difficulties of porting a technology across many operating systems and programming languages. Of course, the technical challenges were daunting, but the political challenges turned out to be insurmountable. We immediately discarded the Smalltalk-like integrated development machine and the virtual machine, concepts introduced by Smalltalk and Lisp, because a VM couldn't possibly be fast enough. We weren't alone in our approach. Many C++-driven companies tried to build programming libraries across many languages. Few succeeded.

The Java approach, shown in Figure 3-1, is fundamentally different. Java's virtual machine simply redefines the machine, providing a lower-level, firmer foundation for portability. Java designers bet that they could overcome performance concerns. It was not a new idea; nor was it a popular one. Over time, they proved to be right—just-in-time compilers improved performance so that the overhead of the JVM became acceptable, and even rivaled compiled languages. The virtual machine, built into Netscape Navigator, proved to be a fantastic launching pad for the Java platform. It's enabled Java to extend into the realm of mobile devices, application servers, and countless software products. When all is said and done, popularizing the idea of the VM may be the most important technical contribution of Java.

Figure 3-1. The JVM took a different approach to performance, security, and portability; most programming languages use compilers to bind them to individual machines, but Java simply redefined the machine

The JVM took a different approach to performance, security, and portability; most programming languages use compilers to bind them to individual machines, but Java simply redefined the machine

Java offers a rich set of interfaces that often delve into operating system territory. Under the covers, Java either implements this type of functionality from scratch, or just calls the native features underneath. Either way, Java developers can count on a rich, consistent library wherever they are. In almost 10 years of software development, though I've seen minor annoyances, I've rarely encountered major problems in porting from one operating system to another. In the end, Sun didn't invent the VM, but Sun did make the VM popular.

Java portability is not without its problems. Graphical user interfaces pose a particularly sticky problem: is it important to maintain portability even at the expense of consistency with the operating system underneath? For example, Swing components, not operating system components, implement the menus in a Java GUI. This arrangement causes problems on the Apple platforms, where the menu for an application traditionally is implemented as a single bar on top of the desktop, instead of the separate menu per application that you commonly see on Unix and Windows. Other notable differences, like security and threading, show up differently on different operating systems. Even filenames can present problems, where having two classes called Account.txt and account.txt would be legal on Unix but not on Windows. But for the most part, Java handles portability very well.

Security

In the age of the Internet, security takes on an entirely new level of importance. Any ubiquitous technology must deal with it, and deal with it well. Sun's engineers recognized this and dealt with the threat from the very beginning. They were fortunate to have the virtual machine to simplify the problem. Unfortunately, other vendors were not so lucky.

Changing threats

Microsoft Windows has been besieged with security problems. The Internet and email make a perfect medium for viruses to spread with frightening speed. Dominant market share, combined with huge holes in Windows and its browsers, make them the target of most Internet viruses.

In fact, blatant security holes in Windows have led to a whole new type of security threat, called adware . Five years ago, it didn't exist. Today, I found 6 million Google hits on the term! As you probably know, adware seeks to exploit vulnerabilities in Internet Explorer to drive up traffic to certain sites and learn about the activities of a user. Most analysts believe that adware has usurped the virus as the top security threat, because these often malicious applications spread so broadly and so quickly. They often lower security settings to enable other types of more serious attacks.

C and C++ also present enormous security concerns. C++ applications have full access to operating system APIs and unrestricted access to every byte in their dedicated memory space. Many versions of the Windows operating system cannot protect one application from another. Given the Internet as the ultimate delivery vehicle through components like ActiveX you can quickly develop unacceptable levels of risk. Given the sensitivity of the data that many of us keep on our machines, these threats take on a more serious dimension.

Remedies in Java

The virtual machine gave Java designers a chance to have a secure foundation on an insecure platform. The advantages deal primarily with the restricted sandbox:

  • Since Sun designed Java from the ground up, it did not need to worry about patching legacy security problems, like those you might find in Unix and Windows. (These are operating systems, but they also are application platforms.)
  • Java, the language and the JVM, grew up after the Internet, so the inventors had the benefit of knowing what types of attacks might occur.
  • Java has a security manager built in at the lowest level, to enforce security policy and to control access to low-level system priorities.
  • The JVM provides a limited sandbox for a group of Java applications, so a malicious or buggy application can't do as much damage as, say, a C++ application might.
  • Because there's no pointer arithmetic, and because Java has strong runtime typing, the JVM knows precisely where a reference is pointing. The JVM can better restrict an application's access to its own memory. Most Java security attacks try to defeat type safety first.

The relative dearth of Java security breaches represents perhaps the biggest compliment to Java's founders. It's just a tough environment for viruses, or adware, or security attacks. The base operating system makes a much riper target.

Moving Forward

The idea of the virtual machine is here to stay. The intermediate virtual machine transforms the basic problems of portability, security, and deployment from nearly unsolvable to routine. If the virtual machine adapts to accept dynamic languages, the JVM will probably be the deployment platform of choice for the foreseeable future. If not, a new virtual machine will need to emerge.

But the problem of portability has proven to be a difficult one. Jython , a dynamic language based on Python but running in the JVM, never quite reached the expected level of prominence in the Python community, particularly because it wasn't fast enough, and partly because the Python community never embraced it. A project to implement Ruby on the JVM, called JRuby , has similar difficulties so far. Still, many analysts predict that the JVM will live long beyond the time that the last Java developer writes the last, lonely line of code.

I'm convinced that the next major programming language will be much more dynamic. It's pretty clear that newer dynamic languages will also have the benefit of a virtual machine. If the lax sales of security books and Windows alternatives are any indication, security just doesn't mean as much to us as we think it does. Still, alternatives may have the benefit of Java's virtual machine. If not, cross your fingers. The next major alternative may not be as secure as Java, because most language designers don't start by building in security first. Until we fix fundamental holes in our processes, our thinking, and our operating systems, security in the languages built on top won't matter much.

The Internet

C evolved from a systems language built to create operating systems. It's a systems programming language. C, and the C++ follow-up language, didn't creep into the enterprise until later. Unlike C++, a very early target for Java was mobile computing, and it evolved very quickly to encompass Internet applications for the enterprise. You can easily see Sun's intentions in four primary places:

  • Java included convenience features to make applications programming easier. Java added garbage collection and memory management, so application developers wouldn't have to deal with these issues. Java included first-class strings, so the platform, rather than the programmer, could deal with moving the individual bytes around. A systems language might want more control.
  • Java's vision for enterprise computing was centered on the Internet. Java built in several libraries that greatly simplified enterprise computing and the growing language always kept the Internet as a central focus. Early APIs enabled everything from communications protocols like TCP/IP sockets to the applet framework that allowed embedded applications in a browser.
  • Java's fathers keenly moved to improve simplicity, at the price of low-level flexibility. For example, though C++ could touch any byte in the system, they knew that the C++ applications community struggled with pointer arithmetic.
  • Very early, Java was targeted at mobile applications , but Sun saw an opportunity to topple Microsoft. Sun took the opportunity, extending the primary focus of Java into the Internet.

Remember this: client/server computing made it very difficult to deploy applications. Thousands of Windows clients, and a distributed network of hundreds of servers to power them, were cheaper than mainframes to buy, but they were horrendously expensive to manage. In the late 1990s, corporate visions changed from client/server computing to networks of applications built with Internet standards, called intranets, existing entirely inside corporate boundaries. When Sun embedded Java into the first version of Netscape Navigator, this vision looked quite possible.

A Consistent Evolving Vision

The ultimate goal for the Internet is this: give all users a single application platform (we call it a browser), and give them the ability to run applications in it. Initially, those applications took the form of applets. It was a simple idea—embed the JVM into a browser, and let the user just download Java byte code that makes up an applet as one more message (MIME) type. The browser would just hand the applet to the JVM. Initially, many companies deployed their first few applets with great success. Later, applets fell out of favor. Over the course of my interviews for this book, I found broadly different views of why they failed:

  • Deployment was hard. Applet developers discovered that they had traded one problem—deploying operating system upgrades and client applications—for another—deploying the ever-changing browsers, and synchronizing virtual machines.
  • Programming was hard. Applet developers had a hard time understanding an alien programming model, and integrating the applets seamlessly with the web page. Applets done well were often magnificent, but not many applets were done well.
  • The Netscape JVM was buggy. Some said that the buggy Netscape JVM killed applets single-handedly. If Netscape had better supported the notion of a pluggable virtual machine, applets might have had a better chance at success.

For whatever reason, applets faded into the background. But Java is a surprisingly nimble beast, at times. In the halls of Netscape, server-side Java emerged. Servlets (a term originally coined by O'Reilly) made server-driven Internet applications available to application developers. Sun capitalized on this movement quickly with a standard, and an open source implementation of a servlet engine called Tomcat . Servlets solved many of the problems of CGI-based applications, and enterprise developers had a new way to deliver applications to a desktop. The vision of an application in a browser remained, but the view logic had moved from client to server.

The server would build dynamic content and serve it to the client. Ironically, this "new" model was little more than a glorified green screen that you might find on a mainframe terminal or emulator. It did have some important subtle advantages:

  • While green screens were stodgy and old, the Internet was cool and new. Users knew how to use them because they had the Internet at home. They liked to use the new systems as much as developers liked to build them.
  • Browsers lacked the raw productivity of keyboard-driven interfaces, but it was much easier to train users on them. The user interfaces provided several subtle enhancements, like navigating through links instead of typing menu choices.
  • The server-side development environments were much more productive than their mainframe counterparts. Development environments, often Windows clients, were much cheaper.

Java's client-side development stagnated. Swing has long been criticized for providing a poor user experience, but the real limitations lie in the learning curves and ultimately the productivity of developers that must grab it by the throat and shake to merely coax a minimal application out of it.

But Java's emphasis quickly moved wholly to the server side, where it remains today. Java Server Pages (JSP) continued the evolution, making it easier for traditional designers to play a role in the development of web applications. More modular designs, with JSP tag libraries, portal components (called portlets), and MVC frameworks, continued the evolution. None of Java's user interface technologies has succeeded on the same scale of web-based applications, driven from servlets.

Moving Forward

The vision of Internet applications is not yet complete. Google is now experimenting with Ajax , which seeks to provide a better experience to users with generated JavaScript and XML that communicates with the server. Applications like Google Maps show that it's possible to create richer applications with JavaScript and active communication between the client and server, but we desperately need a new user interface technology providing the advantages of easily deployed servlets and the richness of applets. JavaScript is broadly available, but it's a haphazard, problem-prone scripting language that's different on each different browser.

My intuition tells me that the ultimate answer won't look much like a browser, but will have many of the same characteristics. You can well imagine that a better marriage between a browser and a dynamic language would make it much easier to give the user a richer experience. One thing to me is clear. The Java community has not had much success with richer clients. The mainstream rich client technologies of Swing and the Standard Widget Toolkit (SWT) keep the programmer at a very low level. Microsoft and Apple both have much better frameworks. While Java does do web-based development very well, increasingly users will demand a richer experience as they have access to more bandwidth and ultimately see the incredible power that a richer experience can unleash.

Enterprise Integration

As the emphasis in Java shifted from the client to the server (Figure 3-2), enterprise integration became more important. Here, the partnership of IBM, Oracle, BEA, Borland, Sun, and others paid huge dividends. They enabled Java connectivity to databases, transaction engines, messaging systems, and any other enterprise system that required a Java connection. The combination of vendor cooperation and support drove cooperation in standards and proliferation of useful connectors that we've never seen before. Java proved to be a good integration platform. Because of the backing of all the heavyweights, Java also became a very safe solution.

Figure 3-2. Java's focus shifted from the client to the server over time[1]

Java's focus shifted from the client to the server over timeDates taken from "The Java Platform, Five Years in Review"; http://java.sun.com/features/2000/06/time-line.html. © 1994-2005 Sun Microsystems, Inc.

Java remains a good language for enterprise integration projects, because of the high number of frameworks that solve so many of the critical problems, like distributed transaction processing. Static typing is much more important for problems on a massive scale, since such problems are harder to test, bugs become more expensive. Relative to C++, in this space, the speed of authoring is more important than the speed of execution, because most execution time is spent inside of the various enterprise transaction, database, and networking libraries.

Moving Forward

Today, Java can talk to just about any enterprise system that's important to you. Beyond integration, Java now provides excellent facilities for mapping object-oriented models to relational databases. You can do distributed coordination of transactions, and manage massive messaging systems with first-class rules engines and workflow. You can reach beyond Java into C++ using a native wrapper called the Java Native Interface (JNI), or using coarse-grained strategies like web services. You've got dozens of remoting strategies available, from the 1990s standard CORBA to the Java-only RMI. Or, you might decide to use many of the lightweight HTTP strategies for remoting and web services. Different standards and free frameworks will help you manage the services for your business objects, do text-based searches, write games, or even write mobile applications.

This is the massive front that a challenger must conquer. But Java has a critical weakness, too. The easy Enterprise problems have been solved, so the key vendors spend most of their time working on the hard problems. That presents a problem for the at-large programmer. As Java moves into increasingly complex places, it has a tendency to leave the programmers of the more basic problems behind. EJBs, the intense proliferation of XML, and the massive web services stacks are just three examples of ever-increasing complexity.

In the end, Java is sacrificing its primary base, exchanging what was productive and hip for something that is tedious and slow, but powerful. Many applications don't need any of the extra enterprise stuff. I'd guess that as many as half of all commercial applications involve a web frontend that baby-sits a plain old relational database. A challenger in that space need not try to make a frontal assault. It need only provide a much more productive solution to a niche problem than Java. Watch a framework called Ruby on Rails. Its sweet spot is the web-based UI on a database. Still today, that's a tremendously important problem. It lets you capture and share information, which can in turn be used in any way imaginable.

Community

The most critical crown jewel for Java is the community. Said another way, Java's market share makes it the 500-lb. gorilla who can sleep anywhere he chooses. Java's community is as massive as it is diverse:

  • Vendors across the industry support Java. Though Sun is the inventor, IBM is perhaps the most important Java supporter.
  • Enterprise developers use Java to do almost everything. Java is at once a mobile computing platform, a web-based applications language, a systems language for enterprise-plumbing code called middleware , and everything in between.
  • Hobby programmers flock in droves toward open source projects. Once the black sheep of the open source community, Java has now become the dominant player.

Standards also play a significant role in enterprise computing. From the beginning, the core Java vendors have collaborated to establish standards. Servlets, EJB, and JSP were three of the most influential standards of this decade. To fend off the image that Java was growing increasingly proprietary, they established a community process.

Java has characteristics that many of us take for granted. You can find good Java developers everywhere. No one ever gets fired for choosing Java. It's mature and ready for outsourcing. You can get education. You can buy components. You can often choose between many implementations of a standard. You can do many things for free. I could go on, but the point is clear. Java's community makes enterprise development safe.

The Importance of Open Source

Everyone wants to build a monopoly for the inevitable benefits of market domination, but the power behind Java's community goes well beyond riding the coattails of market leadership. And one piece of the community, open source software, increasingly defines the Java experience.

In the beginning, open source software powered the servlet revolution through Tomcat. Then, we learned to build with Ant , and test with JUnit , and continuously integrate with products like Cruise Control. Later, Struts software changed the way that we organize web-based user interfaces, and Hibernate led a resurgence in transparent persistence. You could easily argue that the most compelling innovations are happening in open source projects, in many areas:

  • Lucene now provides industrial-strength text-based search.
  • Tapestry is possibly the most promising successor to Struts.
  • Spring rather than EJB defines the way that services are applied transparently. With Spring, you can attach declarative services like security, transactions, and remoting to POJOs.
  • Hibernate is one of the leading providers of transparent persistence.

You can even see the impact of open source software on industry. The EJB 3.0 spec forced vendors to provide a simpler POJO-based API, instead of standing pat and raking in the money from existing EJB 2.x servers. Ant and JUnit changed the evolution of development environments. JBoss created a full open source application server, and is changing the model for software companies.

Now, several companies use the open source community to control certain important technologies. For example, after years of getting hammered in the area of Integrated Development Environments (IDEs), IBM open sourced Eclipse. Now, look at the difference:

  • Though IBM spends a fraction of the money on marketing compared to the past, it has an overwhelming lead in market share.
  • IBM now has the mind share of the fickle open source community.
  • Open source developers contribute eagerly to the Eclipse project, and donate plug-ins for free.
  • IBM still maintains some control over the IDE, and more importantly, it keeps its competitors from controlling any aspect of Java through an IDE.

I'm not suggesting that the open source community is easy to manipulate or control. It's a force of its own. If you're starting a new software company or managing a mature one, you have to consider the impact of open source.

Moving Forward

Community played perhaps the key role in the emergence of Java. Without enticing the C++ community, Java would have started much slower, and may never have attracted the support of the core vendors. Without the open source community, many of the innovations that now define Java might never have happened. The challenges for the next major language are daunting.

If there is to be an ultimate challenger for Java, the next successful language will need to achieve a critical mass quickly. That suggests to me that there will need to be some sort of catalyst, like applets in Netscape. The next successful language will probably also need to nurture a massive open source programming community, if it is to enjoy the variety and longevity of Java. Finally, the next language needs to be politically safe (think Ruby, not C#), so standards can emerge without the constant bickering that can get in the way.

Breaking the Myths

As with all technologies that rise so quickly and become so prominent, it's tempting to worship Java. In fact, many media Java proponents use Java's overwhelming success to defend everything from EJBs to static typing. They make a leap of faith to suggest that Java had to be perfect for it to achieve such widespread success. That's dangerous. In fact, many of the following myths may eventually help lead to Java's demise.

Myth 1: Java's Leadership Is Unassailable

Java is indeed in a comfortable position of market dominance. But storms can come quickly. They can destroy the existing landscape, leaving behind a new legacy. Disruptive technologies occur more frequently than you might think:

  • Consider the recording industry. Records died, and it looks like CDs may die soon, too. Walkmans rose quickly, and are falling just as fast. A combination of an iPod and a Bose Wave Radio can easily replace a whole stereo in many households.
  • Some emerging Third World countries skipped traditional phone systems, in favor of wireless technologies.
  • Digital photography has relegated film to a niche product.
  • You can't find a 51/4-inch floppy disk anymore, and it's getting harder to find a 31/2-inch disk.
  • Closer to home, Visual Basic may be nearing the end of its run. Movement to .NET has proven to be disastrous for Microsoft, for the Visual Basic community.

In fact, Microsoft's .NET environment threatens Java now. Some emerging programming languages draw the attention of some of Java's brightest independent consultants, and frustrating limitations drive away others. All other programming languages have had a limited period of leadership. In the end, this will be true of Java as well.

Myth 2: Java Is a Great Applications Language

Java didn't succeed because it was the best application programming language. It's not even a particularly good application programming language. Smalltalk and Python are certainly more productive. Visual Basic is simpler. Java succeeded because it was able to grab the existing C++ community, and enable them for the Internet. The community, not the language, represents the most important aspect of Java. Some of the very forces that ushered in the Java revolution may well help lead to its ultimate demise. The C++ legacy, necessary to attract the vast existing community, also limits Java in many ways that we'll explore in Chapter 4.

Beyond the syntax of Java, its explosive success forces Sun to make conservative decisions at the language level. It's doubtful, for example, that we'll see aspect-oriented programming baked into the language, as many think it should be. These decisions, designed to maintain backward compatibility, mean Java simply can't evolve as quickly as its competition. All of this means that Java's evolution is limited, when you compare it to its competition.

Myth 3: Java Is the Most Productive Language

When you compare it to C++, Java is indeed quite productive. That's the cloudy window through which we view Java. But Java's not an application language, any more than C++ was. Anyone who's ever used Basic or Smalltalk can tell you about the importance of a rapid feedback loop. Java's compilation requirements and static typing blow away any ability of real-time interpretation or a rapid feedback loop. Static typing is good for preventing some runtime errors, but it's hard on productivity. Java's string handling is limited. Java's syntax lacks features like closures and code blocks (which let you pass a block of code as an argument). Again, Java won because it was more productive than the language that most of us were using at the time. It was productive enough. It won't always be.

Corollary 3a: All languages are about the same

Java was able to displace C++ because it offered significant improvements, like garbage collection, a virtual machine, and better OOP. You can often express more with Java in fewer lines of code than you can in C++. The same holds true when you compare Java to some other languages. Languages like Lisp and Haskell offer a higher level of abstraction and a radically different paradigm. Languages like Ruby are far more dynamic, and offer much better access to the building blocks of the language through metaprogramming. Features like code blocks and continuations impact the way you organize and use your libraries, and Java doesn't support either one. In Java, you often have to work much harder to achieve the same result.

Myth 4: Commercial Interests Drive Most Java Innovation

While industry is driving some significant innovation, you could well argue that the most important innovations, like lightweight containers (Spring), web-based application models (Struts and Tapestry), and transparent persistence (Hibernate), are all happening in the open source community right now. These are the ideas that push Java beyond its intended boundaries. In fact, industry goals often hamper rapid innovation:

  • It takes time to synchronize massive integrated suites of products. That's why you have to wait so long between releases of WebSphere.
  • It takes time to build and test on the scale that's necessary to make big money, in the face of open source competition.
  • It takes time to create standards, and more time to adopt them.
  • The JCP tries to use the knowledge of experts to invent standards, instead of standardizing inventions born out of experience from successful implementations.

More and more, customers look to open source software to solve critical problems, because they innovate so well. Just as you've witnessed the rise of open source frameworks as a major force, the next popular programming language could well emerge from the open source community.

Myth 5: Big Things Usually Come from Likely Sources

The last few major programming languages have mostly come from unlikely places. The last two didn't even come from major software companies. C came from Bell Labs, a communications company. Java came from Sun, a hardware company. The next popular language will likely come from an unlikely source as well. I don't count C#. It's effectively a Java clone. And the roots of success of Visual Basic came from a small company, operating on a razor-thin budget out of a garage in the Pacific Northwest, called Microsoft.

Java is a mere programming language. Like all languages, its moment in the sun, and its leadership, will prove to be limited. The question is not if, but when.

Looking Ahead

So far, I've tried to paint an accurate picture of Java's success. I owe much of my career to the fathers of Java, and the incredible run of success it's had. Still, I believe that Java is not the unassailable juggernaut that many believe it to be. I think that Java is drifting away from the very developers who made it successful, those who could download a relatively simple language and environment to get an applet or servlet running quickly. Further, some of the very compromises that made Java attractive to the C++ base, like primitives, static typing, and a C++-like syntax, are beginning to work against it. Simply put, Java has reaped the benefits of effective compromises. In the next chapter, we talk about the costs.

Notes

  1. Dates taken from "The Java Platform, Five Years in Review"; http://java.sun.com/features/2000/06/time-line.html. © 1994-2005 Sun Microsystems, Inc.
Personal tools