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.