O''''Reilly Network For Information About''''s Book part 5 ppsx

2.3. Clouds Open
The sound and fury of the Java storm caught many of us off-guard. And why not?
It came from an unlikely source, was delivered in an unconventional vehicle, and
defied conventional wisdom regarding performance of interpreted languages. Other
than the language, nothing about Java was conventional at all, including the size of
the explosion. In retrospect, you can look back and see just how well it filled a
void. Figure 2-3
shows the many ingredients that come together to form the perfect
storm.
Figure 2-3. Many forces formed the combined ingredients that led to a perfect
storm

2.3.1. New Economics
The jet stream that powered this storm emerged from a series of standards: TCP/IP,
HTTP, URI, and HTML. The Internet gathered steam, and Sun took full advantage
with Java. The Internet was everywhere. Java was cool. The Java developers
quickly built the API set that would allow developers to code for the Internet,
including TCP/IP APIs for communication, and applets for building user interfaces
that you could embed in a browser. JDBC allowed database access.
The perfect combination formed by the relationship between Netscape Navigator
and Java drove each company to new heights. Through Netscape, Sun was able to
put Java in front of an incredible number of developers, nearly instantaneously.
Through Java, Netscape could showcase smart applications that looked cool, and
were simultaneously practical. The Navigator/Java combination seemingly solved
the most critical problems of client-server computing: management and
distribution. If you could install a browser, you could then automatically distribute
any application that you wanted through the browser. Java had the perfect

economic conditions for success. Java found an important ally in the bean counters
that liked the manageability of the green screen, but the productivity and usability
of the fat client.
Customers wanted solutions, and Sun realized that Java would give them what they
wanted. Sun immediately saw the opportunity it faced. With the open standards
around the Internet and the Java language powering it, Solaris on Sun servers
would be a compelling, and even hip, alternative. Above all, Java made Sun safe.
Because its virtual machine ran in a browser and on many different operating
systems, some hard decisions didn't seem so hard. You could try out a deployment
scenario. If you didn't like it, you could just move on.
The new jet stream was in position to feed power to the growing storm.
2.3.2. C++ on Prozac
When Lucene founder Doug Cutting called Java C++ on Prozac,
[*]
I immediately
liked the comparison. Because of its C++ syntax, Java found an impressive waiting
community of developers looking for a solution. They moved to add a hip Java,
and Internet experience, to their resumes. They stayed because they liked it. Java
had most of the benefits of C++, without the problems. The similarities of the
languages made it easy to learn. And Java was liberating, for many reasons:
[*]
TheServerSide.com, "Doug CuttingFounder of Lucene and Nutch," Tech Talk
(March 10, 2005);

 Java provided more structure in places that needed it, such as providing
interfaces instead of inheritance.
 Java eliminated the burden of pointers, improving stability and readability.
 Garbage collection got easier, because the JVM automatically took care of
abandoned references.
 Java allowed a much better packaging mechanism, and simplified the use of

libraries.
 Java cleaned up problems like nested include files and macros.
2.3.3. Architecture
The benefits of Java went beyond economics and C++. I can still vaguely
remember the first sentence that I saw describing Java. Sun said it was a portable,
safe, secure, object-oriented, distributed programming language for the Internet.
Those words were all buzzwords of the time. For C++ developers, Java
underpinnings made significant strides:
 The JVM allowed unprecedented portability. Many experts believe that the
JVM, and not the language, is the most important feature of Java. Sun
marketed this capability brilliantly with the acronym WORA. Java
developers the world over recognize those letters as standing for Write
Once, Run Anywhere.
 Java published the byte code specification for the JVM. People who want to
build their own JVM or build a language on the existing JVM standard can
do so, or even modify byte codes of existing applications. Frameworks like
JDO do modify byte code with great success.
 While C++ allowed unrestricted access to application memory, Java
restricted access to one area of the JVM called the sandbox
. Even today, you
see very few exploitations of Java security.
 The Java metamodel, made up of the class objects that describe types in
Java, allowed sophisticated reflective programming. Though it's a little
awkward, the capabilities of Java extend far beyond the basic capabilities of
C++. The Java metamodel enables frameworks that increase transparency,
like Hibernate (persistence) and Spring (services such as remoting and
transactions).
 The fathers of Java saw the importance of security, and baked it into the
language. Java introduced a generation of programmers to the term sandbox
, which limited the scope and destructive power of applications.

 Java had improved packaging and extensibility. You could effectively drop
in extensions to Java that transparently added to capabilities of a language.
You could use different types of archives to package and distribute code.
Both the low-level grunts and high-level architects had something to love.
Businesspeople had a motivation to move. At this point, if all else had failed, Java
would have been a successful language. But it didn't fail. The winds just kept
picking up speed, and the storm started feeding on itself.
.4. Fury Unleashed
Applets captured the imagination of programmers everywhere. They solved the
deployment problem, they were cool, and they were easy to build. We're only now
finding a set of technologies, based on the ugly and often objectionable JavaScript
language, that can build rich content for the Web as well as Java did. Still, applets
started to wane.
Even today, I think that applets represent a powerful idea, but they fizzled out for
many reasons. The Netscape browser's JVM was buggy and unpredictable. Further,
with such a rapidly evolving language, applets presented many of the same
problems that client-server computing did. You may not have to maintain
applications, but you still had to maintain the browser. After you'd deployed a few
Java applets, you had to worry about keeping the right version of the browser on
the desktop. As the size of the JVM grew, it became less and less likely that you
could install a JVM remotely. Even if you could, Java versions came out often
enough, and were different enough, that new applications frequently needed to
materialize. But a few mad scientists at Sun were up to the challenge again.
James Duncan Davidson: Why Java Won
Author of The Rise of Java

James Duncan Davidson is a freelance computer programmer,
photographer, author, and speaker. He invented both Ant and Tomcat, two
of the most successful Java open source projects ever. His persistent
efforts at Sun led to open sourcing both projects. He is now one of the

best-selling authors of Apple operating system books.
What do you like
best about Java?
JDD: At the time, it seemed like a really good
idea. Mostly, for what Java was designed for,
they got it right. Of course, it's a strongly
typed language, which for some purposes is
great, and other purposes not.
Why do you think
it's so successful?
JDD: I think it comes down to the fact that
server-side programming in Perl and the like
was inefficient, and 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.
I may be biased because of my involvement
with servlets, but Java without the server side
wasn't that interesting. It still isn't. Sure,
J2ME is on bazillions of mobile devices, but
there aren't that many apps thereand the APIs
there are limited unless you actually make the
cell phone.
What don't you
like?
JDD: Strong typing. Reliance on APIs rather
than frameworks. That's a subtle but
important distinction. The increasing
complexity of even basic APIs. For example,
you can't just write a servlet anymore, you

have to write a servlet, then edit an XML file.
They're killing off the approachability that
helped servlets get off the ground. W
ith it, the
rest of the server stack gets more and more
difficult to work with.
And reliance on tools to make it easy is a
cop-out.
As well, I don't like the massive monolithic
approach to "Editions." Most people don't
need J2EE. They need a web container. End
of story.
I also don't like the incredible jump to
complexity that Java seems to engender in
people. No other platform has grown as fast
and as elephantine as Java. Other platforms
are as capable, but are 5% of the size. There's
an architectural reason for that. And, really,
Java the language isn't at fault. Java the class
libraries are. They encourage massively
inefficient design. Ever see a stack trace
come out of a JSP/servlet/J2EE container?
The 44 pages of stack call should be a hint.
How does Java
hold you back?
JDD: It doesn't. I don't use Java much
anymore. I use other languages like Python,
Ruby, and ObjC.
And I wish that more tools would just
remember the lessons of Unix: small pieces

loosely joined. There is no one übersolution,
and at the end of the day, if you can take two
tools and pipe stuff between them, you have a
more powerful and flexible solution than any
monolithic beast. And one in which users can
discover uses far more powerful than you can
imagine.
What emerging
alternatives make
sense to you, if
any?
JDD: Ruby on Rails has picked up an
amazing amount of traction for server-side
stuff. If you need to slush around mass
amounts of content, there are content
databases (like MarkLogic) that are
interesting that use XQuery to work with the
stuff inside. On the GUI front, well, Java
wasn't a contender, so everything is already
an alternative.
What would
prompt (or did
prompt) you to
move away from
Java, or .NET?
JDD: I shifted focus into the GUI application
space. Java and GUIs don't mix. Friends don't
let friends Swing.