5.1. Java Raises the Bar Each new language is subject to the rules of its time. If you think about new inventions in the world of music, you'll see the same principle in play. Early in the recording industry, a record label would sign an artist to a specified contract, manufacture records, promote them on the radio, and distribute them in stores. You find some of those features today, like many of the roles in the production cycle and the importance of airtime (on radio, and now TV and the Internet). Changes in standards force the industry to retool. Some are relatively minorchanges in record speeds simply forced manufacturers to add capability to record players and recording equipment. Others will almost certainly be more radical. These changes require a critical mass to take holdCDs achieved a critical mass, but eight-tracks did not. Sometimes, disruptive changes completely redefine the organization and very fiber of an industry. Our kids are redefining the way music is distributed through services like Napster and iTunes. Some artists are distributing their music entirely over the Internet, and they are cutting the publishing industry out of the equation altogether. New programming languages work in much the same way. Every language leaves behind a legacy. Sometimes, changing languages embrace the legacy. For example, you compiled your C programs into a DLL or an executable. You could take advantage of your C code from C++ by buying a new compiler. You could even use C++ to write procedural code or object-oriented code. C++ changed the way we think, but it did not change much of the machinery. The C programming language was also disruptive in many ways. Java, too, was disruptive, redefining the rules of the game. Kids like to be able to download songs like "Macarena" instantly, so the old music stores aren't cutting it anymore, and they are closing their doors. Don't even try to open one, unless you plan to bankroll it with your own money. By the same token, we like the convenience of the JVM, the massive open source community, and the focus on the Internet, leaving a higher standard for the next major applications language. 5.1.1. Portability Remember our technical crown jewels. Java commercially introduced the concept of a virtual machine . It redefined the landscape. You compile Java into intermediate byte code that runs in a virtual machine. We've now gotten a real taste of the advantages of the virtual machine. The next major applications language will almost certainly support a virtual machine. You just can't ignore the benefits: Security If you can secure the virtual machine, it's much easier to secure the language. Portability The virtual machine provides a common, clean foundation for the language. Extensibility If your language turns out to be inadequate, you can always change the byte code. Java extensions like JDO (transparent persistence) and AspectJ use byte code enhancement to extend the Java language effectively. Interoperability Lower-level byte code makes it possible for one language to use the same deployment infrastructure, and even run side by side with other languages. So, the virtual machine is important. I'll go one step stronger. The next commercially successful language should have a version that runs in the JVM. That would help a language overcome many obstacles, both political and technical. Dion Almaer: Why Java Will Be Hard to Replace Dion Almaer is the founder and CTO of Adigio, Inc. He is an architect, mentor, pragmatic, and evangelist of technologies such as J2EE, JDO, AOP, and Groovy. He is the former editor-in-chief of TheServerSide.com J2EE Community and is a member of the Java Community Process, where he participates on various expert groups. You've been a Ruby on Rails proponent. Do you see Ruby as a potential replacement for Java? DA: As much as I like technologies such as Ruby, I am skeptical as to how to get them used in the mainstream. There is too much power behind the Big Two VMs (JVM/CLR). "You are saying I should bet my Fortune 500 enterprise on a Japanese Mormon named Matz?" What are the big obstacles? DA: Inertia is a serious concern for large companies. What is the roadmap for Ruby? Where are the standards? What is the quality of the various modules? How is Ruby on the mobile phone? How might it overcome those obstacles? DA: Ruby is a top language with some amazing frameworks on top of it, but to get to the next level there probably needs to be more. I would love to see JRuby and Ruby.NET really take off. The bulk of the arguments are political, but they are still very valid. There are many great things written on top of the JVM. Ruby feels best for me as a language (for certain tasks), but the platform is harder to sell. If I can get a merger of the two, I am off to the races. This is why Groovy had promise and Java guys were excited. The language would be "Java" to their bosses, but they could do scripting in Groovy on the side. There is a lot of legacy code out there, so it can be hard to migrate to a different platform right now, unless there is a true migration plan. Something like Ruby needs its "killer app." Many think it is Rails, but is that enough? What type of projects will be run on Rails? I guess we will see. Don't get me wrong, most of my thinking has been because I want the industry to move to languages that are more dynamic. I think we need to but I am skeptical. 5.1.2. Internet Focus Java set a new bar for Internet integration , and Java's users took full advantage. Corporations use the Internet internally to discriminate information and control the deployment costs of an application. Businesses use the Internet externally to reach their customers and partners. Enabling applications for the Internet has become the most important problem that a business solves, except maybe database integration. Java enabled a whole new generation of Internet applications, with the servlet programming model, JSP as a compiled template language, and a whole suite of enterprise libraries. The next successful language will have to do the Internet, and do it better than Java. The Internet has at least two dimensions: interfaces for computers, and interfaces for people. For people, the next language should build more powerful interfaces faster than you can build them in Java. I don't think it's enough to just build simple HTML. You need to be able to build a page that can preserve a common layered look and feel throughout an enterprise, so the next language will need to support some kind of component model. Also, users are just beginning to understand that HTML is not enough. Applications like Google Maps and Google Mail stretch HTML and JavaScript to new levels. That's going to be very important to the next successful language. In fact, many of the consultants I interviewed for this book believe that HTML is broken in fundamental ways. A broadly successful new language could conceivably present a higher abstraction that makes it easier for the industry to retool, piecemeal. Ruby on Rails and Ajax technologies both seem to be moving in this direction. 5.1.3. Interoperability Bridging from Java to an emerging language will also be important. Of course, if the new language embraces the JVM, interop at lower levels will not be a problem. Interop on the Internet will undoubtedly play a critical role. I think that leads to three important capabilities: XML , web services, and service-oriented architectures. 5.1.3.1. XML and structured data Programming has always meant working with data, yet Java doesn't let you declare nested structured data very well. In Java, you see a proliferation of XML, even where it offers little tangible value. For example, metaprogramming and all kinds of configuration require you to express structured data. The next language should let you declare and express structured data, cleanly and natively. Still, structured data and a language to describe it are important. If you're dealing with structured data on the Internet, you're probably dealing with XML. The next successful language should let you deal with XML productively, and with good performance. In Java, we've dealt with that problem using parsing schemes, query languages, and binding frameworks. A parser cracks open XML and lets you break it into its constituent parts. A binding framework lets you take an object model and convert it directly to XML, or deal with XML as if it were a native object model. XML query languages like XQuery can reach into a complex XML document to retrieve o ne named piece of data. It's reasonable to expect an emerging language to support all three XML technologies, and most of them do, to various degrees. 5.1.3.2. Service-oriented architecture (SOA) A common structured data format is not enough to bridge two languages. You also need a communications mechanism. One trend in languages like Java is to build loosely coupled services, available on the network, and let them communicate with simple messages, with an XML payload. It's a good strategy for interop, for many reasons: SOA works best with coarse-grained architectures, or calling big chunks of code. Interop between languages is a coarse-grained problem. SOA is hot. Since it's politically popular, support and mindshare will likely remain high. SOA uses Internet standards. That means you can leverage existing infrastructure, like security and existing message protocols. I'm not sure that web services, as defined by IBM or Microsoft, has staying power. I do believe that a lighter form of web services, called REST, may last. REST stands for Representational State Transfer, and it promotes using services the way Internet sites have used them for years. Like the Internet, REST views the network as a collection of resources rather than a collection of methods (like CORBA or traditional web services.) A REST-based resource returns a representation of itself, usually in XML form. REST allows and even encourages links. REST-based services are based on well- understood, mature APIs, so unlike the fragile traditional web services stacks, they integrate well with other technologies. They can also rely on existing infrastructure to cache content, build links, or secure communication. It's a powerful paradigm shift. So, Java provides the first set of rules, shown in Table 5-1. If you want to run this river, you'll need to meet the improved standards set by Java. To do anything less means death. Table 5-1. Java's legacy requirements Rule Description JVM and/or Microsoft Common Language Runtime (CLR) Run in the JVM, or at a bare minimum, run in its own virtual machine. Internet focus Enable Internet applications. Internet user interfaces Allow richer Internet user interfaces. Service layer Provide an SOA-style integration with Java. Web services Allow some type of web service, whether it's the full web services stack or REST-based web services. XML Provide a rich, productive XML API. . editor-in-chief of TheServerSide.com J2EE Community and is a member of the Java Community Process, where he participates on various expert groups. You've been a Ruby on Rails proponent. Do you see. deployment costs of an application. Businesses use the Internet externally to reach their customers and partners. Enabling applications for the Internet has become the most important problem that a business. languages, and binding frameworks. A parser cracks open XML and lets you break it into its constituent parts. A binding framework lets you take an object model and convert it directly to XML, or deal