o If you look at the majority of programmers building new technology,
the majority of tools in any language will fall short of being
able to deliver an end-to-end solution. This is an environments
problem, not a language problem. Any Powerbuilder gurus out there?
How much expertise is required to build real-world enterprise apps
using Powerbuilder?
o Java is an elegant programming language. Comparisons to C++ are apt,
performance comparisons to C++ are irrelevant.
o Garbage collections is extremely useful.
o Java's performance is sufficient for a majority of Web-based applications.
The performance criticism like the cross-platform hype is irrelevant.
o Applications are NOT going to always be built the same way they are now.
The same language doesn't have to be scalable to a complete end-to-end
enterprise application. Dynamic, decentralized, and mobile are very
real application requirements. It is extremely difficult to integrate
all the enterprise to fit into one application genre.
o Your application doesn't need to scale to thousands
upon thousands of threads in a single JVM. Even if you need it to, you
can always tweak the memory settings with pretty good effects.
o Java apps may not be idealy suited for the casual web visitor,
but for business users who need access and use of a particular
functionality through the Web, 10 seconds is irrelevant most of
the time. If you could add up all the time people spent waiting
for Excel or Word to load, a finer grained app suited to the
individual's task is worth waiting a couple of seconds for.
Greg
Rohit Khare wrote:
>
> I know there's been some controversy over having Mark's
> thesoftwareview directly crossposted to FoRK, but this column of his
> is spot-on. The Java VM dream never overcame OS-level differences for
> threading, etc. The Java programming language is a nice, but by no
> means complete effort. The JavaSoft APIs are another story entirely :
> they're trying to tie their shoelaces while running to recreate an
> entire OS-independent OS. Not to mention the disastrous branding
> mismanagement surrounding version numbers, product naming,
> hype-of-the-week, and closed-source.
>
> 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