Moral: listen deeply to the point Adam is making about getting it
right the first time.
Sometimes the Second System Effect is no problem at al... there is NO
second system. Build one to throw away in the privacy of your own
subnet.
Rohit
>Date: Sat, 08 May 1999 13:15:13 -0700
>From: Mark Kuharich <mark@mrkint.com>
>Reply-To: mark@mrkint.com
>Organization: MRK International, L.P.
>To: theSoftwareView@softwareview.com
>Subject: thesoftwareview: Java is dead ... Long live Java!
>http://www.softwareview.com/
>Java is a software technology platform invented at Sun Microsystems,
>Incorporated and created by Doctor James A. Gosling. It consists of not
>only the Java programming language itself, but also of the Java virtual
>machine and its associated core Java Class files and applications
>programming interfaces, or API's.
>
>Java has the potential of becoming the de facto programming language for
>the Internet and World Wide Web, and the standard for cross-platform
>executable content. Its mantra is "Write once, run anywhere". Java
>annihilates the switching costs associated with portability between
>operating systems for software applications.
>
>But, I did not come here today in praise of Java. I came here to bury
>it. Java is dead. Java is whistling past the graveyard. Here are the
>reasons why Java is dead. But, the Java emperor has no clothes. Here
>are the reasons why Java has no clothes. You can put a fork in Java
>because it is finished.
>
>Java lacks true platform independence. This is a myth. The only two
>platforms that Sun targets for the latest, major releases of the Java
>Development Kit (JDK) are Sun Solaris and Windows. Sun leaves Java
>implementation upon other platforms to its partners. As a result, there
>is always a significant lag time between Sun Solaris versions of key
>Java software technology and versions for other operating system
>platforms like Linux, the Macintosh, and HP-UX. Java's client-side
>story is a joke. I have personally attempted to create cross-browser
>and cross-platform client-side Java applets. I wanted to ensure that
>the applets, housed upon different versions of Internet browsers and
>different versions of operating system platforms, all returned a uniform
>look, feel, and behavior. The frustration involved to perform this
>Herculean endeavor made me want to pull my hair out.
>
>Jim Frost writes, "Like a good Merlot wine, Java has been improving with
>age - but it is still young, and its youth shows. Yes, you can produce
>a single executable file that runs pretty much anywhere, but usually you
>cannot just write the code once and be done with it. You write the
>code, test it everywhere, tweak it for platforms where it does not work
>and repeat until you have something that works everywhere you care
>about. This has led some developers to joke and quip that Java is
>"write once, debug everywhere." What is worse is that what you gain in
>development time you lose many times over in testing costs because you
>have to test on every Java Virtual Machine (JVM) on every operating
>system platform - potentially dozens of JVM's on Microsoft Windows
>alone.
>
>In practice, Java applications tend to be so robust that beta testing
>becomes much more difficult: Most exceptions in graphical user interface
>(GUI)-based applications are caught by the GUI package - the Abstract
>Windowing Toolkit (AWT) or Swing, allowing the application to continue
>operating (albeit with reduced functionality). Often this means that a
>button or menu item simply does not seem to respond, behavior that is
>generally not seen as being as serious as dumping the core or locking up
>the entire machine.
>
>Java's performance is too slow. Java is an interpreted language, rather
>than one being compiled natively. Java is universally castigated for
>its poor performance relative to C++. These criticisms are
>well-deserved. Java achieves barely half the performance of C++ across
>a typical code base, and Java's GUI libraries are rarely accused of
>being too efficient. Who is not familiar with the experience of
>visiting an Internet or World Wide Web site that has a Java applet
>embedded within it, and waiting interminably for your local web
>browser's JVM to load and display the applet?
>
>Some of the popular opinion of Java's poor performance is the result of
>Sun's exploitation of the exploding Internet Web browser market as a
>Java launching pad and platform. While this got Java into the hands of
>thousands of developers and millions of users, applets highlight the
>worst parts of Java (AWT, code and run-time size and raw performance).
>The ploy worked as a means of reaching critical mass but it totally
>destroyed any chance of achieving high degrees of stability anytime
>soon, owing to the mass adoption of very immature Java applet
>technology. Most Java runtime environments on user systems today are
>still based on JDK 1.0.2 technology that is more than two years
>out-of-date, and the dependency upon the Internet web browser vendors to
>update their technology has seriously impeded the influx of features in
>newer releases.
>
>The mark-and-sweep garbage collection algorithm used by Sun's existing
>JVM's is essentially the same as the one used in the first LISP
>interpreters - it is mid-1960's technology."
>
>Java lacks sufficient development tools. The newness of Java ensures
>that its development tools are relatively immature and weak. A case in
>point: Sun's Java Development Kit (JDK) continues to consist of crusty,
>command-line driven utilities. Java tools and runtimes used by most
>developers are primitive and/or buggy. In contrast, Microsoft's Visual
>Studio development suite is a tool that C++ software developers love.
>It has been honed through years of experience in learning from C++
>programmers and discovering their needs.
>
>There are not enough existing JavaBean software components. The paucity
>and scarcity of JavaBean components in relation to the abundance of
>Microsoft VBX, OCX, ActiveX, and OLE components is glaringly obvious.
>
>Java also has questions of database access. Does the Java Database
>Connectivity (JDBC) specification offer as speedy database access as
>native database drivers?
>
>Java has questions of scalability. How many threads can you create
>safely with a Java applet before the JVM loses its mind?
>
>Is Java even needed at all? Other technologies like Visual Basic, C++,
>and COM can meet your needs. Plus, it is absurd to ask users to rewrite
>all their software using Java. The reality is that we live in a
>heterogeneous world filled with pre-existing legacy software objects
>written in other languages.
>
>There is also the question of Microsoft's stance concerning Java. The
>company that possesses the monopoly in the world's desktop personal
>computer operating systems is clearly not a good citizen within the Java
>community. The omnipresence of Windows (in one flavor or another) is
>the reality for developers. Ninety-five percent of desktop applications
>run under Windows. Microsoft has a ninety-five percent market share of
>desktop personal computer operating systems and a ninety-three percent
>market share of desktop personal productivity applications like
>spreadsheets or word processing. There are and will continue to be a
>very large number of applications written only for the Windows
>environment.
>
>Java lacks conditional compilation and a preprocessor. Doug Bell
>writes, "eliminating conditional compilation actually makes it more
>difficult to maintain code since entirely separate files must be
>maintained. Conditional compilation has been useful for debugging code
>and/or assertions, performance profiling, feature enabling/disabling and
>demonstration versions, backward compatibility, and making complex
>changes to a working product."
>
>There is also the question of whether or not Sun Microsystems can
>reliably release updates to the Java software technology platform in a
>regular and timely fashion. Sun's HotSpot JVM technology reminds me of
>sightings of either the Abominable Snowman, Big Foot, the Loch Ness
>Monster, or Sasquatch. There are rumors that these exist, but no one
>has either seen them or can confirm or prove that they exist.
>
>Java does not currently support user-defined operator overloading and
>there are no signs that it will ever be incorporated into the language.
>One could speculate that this might change once the ISO standards
>process gets underway. Java also lacks support for concrete types and
>lacks support for sophisticated high performance numerical computing.
>Also, Java's floating-point arithmetic is blighted by five gratuitous
>mistakes.
>
>Java has not succeeded as a platform both because there is no real
>demand for an alternative to Windows and because Java is not a platform,
>except by the widest definition of the term: programmers write to its
>API's, and applications run on it. From the beginning Sun's problems
>were its lack of pull with the market creators - that is, the software
>developers - and, more recently, Sun's waffling on how much of Java to
>release to independent standards bodies. The result is that
>standardization efforts have been sluggish.
>
>Bjarne Stroustrup has said, "If users know what language you are using,
>there is something wrong. You shouldn't be able to tell. I have never
>liked proprietary languages. You cannot entrust one person or a
>corporation with the control of a language. You need an open forum for
>discussion. No matter how open a corporate language claims to be, it
>will inevitably exclude people who do not play by the same rules as the
>corporate owner - and those rules may not be in the best interest of the
>language's evolution.
>
>Much of the relative simplicity of Java is - like for most new languages
>- partly an illusion and partly a function of its incompleteness. As
>time passes, Java will grow significantly in size and complexity. It
>will double or triple in size and grow implementation-dependent
>extensions or libraries. In the year of 1995, Java had two hundred API
>method calls, today, it possesses over 1,600. The JDK 1.0 contained 212
>Java Class libraries and interfaces in eight packages. Today, Java
>contains at least 2,000 Classes and interfaces in 98 packages. That is
>the way every commercially successful language has developed. Just look
>at any language you consider successful on a large scale. I know of no
>exceptions, and there are good reasons for this phenomenon."
>
>Brett Glass writes, "Sun's Java strategy should focus on the JVM. Sun's
>problems are the result of three strategic mistakes that Sun made at the
>very outset. Together, these errors threaten to undermine Java fatally
>and seriously.
>
>The first mistake, as is all too common when avowed technologists
>attempt to market new products, has been one of positioning. Instead of
>pushing Java's greatest strength, the "virtual machine" technology that
>allows an application run on nearly any operating system safely and
>without recompilation, Sun has cast Java more as a language that just so
>happens to be cross-platform. This does a disservice to the most
>important and least known feature of Java's technology: that it is
>possible to compile nearly any existing computer language - not just
>Java - to run on Java's run-time engine. By putting the cart before the
>horse, Sun has neglected what must be one of its primary goals: to
>enable users to choose its products despite the nearly complete
>Microsoft Windows monopoly.
>
>Sun's second mistake, which follows directly from the first, is how it
>has chosen to name Java and its components. Sun gave the language a
>short and catchy name and called the engine by the much more awkward
>"Java Virtual Machine". This name perpetuates the illusion that the
>"Write once, run anywhere" aspect of the technology is secondary to the
>language. Opponents have capitalized on this tactical error by
>propagating the incorrect notion that Java is "just a language".
>
>But Sun's most telling error has been its failure to keep complete
>control of the virtual machine. With legions of programmers and plenty
>of cash to hire more, Sun should not have lazily allowed other vendors
>to implement the cross-platform engine. Netscape, Hewlett-Packard, and
>others should never have been entrusted with this all-important
>component. Had Sun implemented the virtual machine itself for all the
>important operating system platforms (as it has now begun to do,
>belatedly, with its Activator Plug-In technology), it would have had a
>hot product to license or even sell directly to end users for an
>immediate gain. (Sun's Java Software Division, which is responsible for
>Java, has yet to turn a profit.)
>
>What is more, were Sun the sole author (or nearly so) of Java virtual
>machines, 100 Percent Pure cross-platform compatibility would be easier
>to achieve, and divergence of the language would be a non issue. Java
>the language could be released to standards committees with no negative
>effect on the platform's viability, eliminating the most strenuous
>objections to Java as a whole. Any language or compiler that created a
>program for Sun's virtual machines would automatically be able to run on
>any system, allowing users to choose alternative hardware platforms and
>operating systems - including Sun's - with confidence."
>
>Sun has done a very poor job of leading and holding the Java movement
>together as a coalition. Examples of fractures and tears in the seams
>include: Transvirtual Technologies Incorporated's Kaffe virtual machine,
>the Hungry programmers' Japhar virtual machine, Cygnus Solutions'
>Project Mauve, Hewlett-Packard's Chai technology and their movements
>concerning hard real-time Java, IBM's lack of support for Jini, and
>Microsoft's complete and total lack of support for Java itself. These
>are widely viewed as symptoms of disaffection with Sun over its handling
>of Java licensing, and its dual role as keeper of the Java standard and
>a profit-making company.
>
>"Sun was way too scared of Microsoft, and as a result they created a
>contract that didn't help them. Java is in the die-back stage - it's
>going into niche markets." No less a software industry luminary than
>Linux creator Linus Torvalds spoke the above quote at the Oracle Open
>World conference on November 11th of the year 1998. Torvalds is the
>very personification of the open-source software movement. And his
>quote bespeaks a damning and profound question: Did Sun Microsystems'
>tight grip upon and control of Java prevent the software technology
>platform from achieving success? Though Sun has recently taken some
>steps toward open-source with Java, GNU Public License (GPL) purists and
>proponents of BSD type licensing argue that Sun has not gone far
>enough. Sun still retains tight control over Java. And if you ever
>contribute Java bug fixes to Sun, there is no guarantee that your fixes
>will be redistributed to the entire Java community.
>
>Long live Java! Luddites and nay sayers continue to insist upon writing
>Java's epitaph. As Mark Twain would paraphrase, "The rumours of Java's
>demise have been greatly exaggerated."
>
>Java is an elegant, modern software technology platform ideally suited
>for network applications. Java occupies a strong middle ground between
>the lower-level, performance-oriented languages used by a lot of
>commercial software, and the high-level languages favored for quick and
>dirty (for example, departmental) applications. It is easier to use
>than C++ for enterprise application development and less of a headache
>than languages such as Visual Basic. Java shares a lineage with other
>interpreted languages (remember UCSD Pascal?), but it has a couple of
>things going for it that none of its predecessors had - vast
>distribution of its core code and runtime engine, thanks to Web
>browsers, and a serendipitously excellent object-oriented architecture
>for the needs of distributed computing.
>For the rest of this article, go to http://www.softwareview.com/
>Mark Kuharich
>
>*** THESOFTWAREVIEW post by: Mark Kuharich <mark@mrkint.com>
>
>_________________________________________________________________
>Internet site, web based archive, and home page at
>http://www.softwareview.com
>
>Help support my newsletter and web site by purchasing items through
>Amazon.com from my web site
>http://www.softwareview.com/Amazon/
>
>If you ever wish to remove yourself from "the Software View"
>mailing list, please send mail to "majordomo@west-point.org" with the
>following command in the body of your email message:
>
> unsubscribe thesoftwareview
>
>To unsubscribe, mailto:thesoftwareview-off@west-point.org
>For help, mailto:listhelp@west-point.org
>To change address, mailto:thesoftwareview-owner@west-point.org