Clay Shirky’s appeal on
oreilly.com for OEMs to keep bundling Java with Windows rings hollow. In the
name of preserving the diversity of the “computing ecosystem,” Shirky decries
Microsoft’s decision to debundle its JVM from Windows XP, calling it a
“terrible blow.”
In fact, it’s nothing of the sort. What right does Java have more than Perl, Python or Tcl to be bundled in with Windows? It certainly isn’t client-side
applications. Java’s strong suit is in server applications: ones that are
heavyweight enough to require a server operating system, and with installation
procedures complex enough that a separate install of a Java virtual machine is
more than acceptable.
The removal of the JVM will be of no consequence to the overwhelming majority of Windows XP users.
The real issue behind the debundling of the JVM is the ongoing fight
between Sun and Microsoft. The removal of Java from Windows XP sends a
negative signal about Java at a time when Microsoft wants to push .NET. After
all, if Java depends on being bundled with Windows for its popularity, it
doesn’t say a lot about its strengths as a platform in its own right.
Sun is big enough and nasty enough to slug this one out for itself.
Sign the anti-petition here! What difference does it make whether there’s a JVM or not?
On the contrary
On the contrary to you statement Mr. Dumbill, there is a fairly significant demand for JVM on the client side especially in the enterprise environment considering the fact that Java is making deeper and deeper inroads into enterprise on both client and server sides. Java is yet to fulfill its promise on the desktop taking into consideration ever increasing CPU speeds and cheaper memory. As a manifestation of this process you can witness proliferation of such enterprise level desktop applications as Borland JBuilder, Sun Forte, TogetherSoft Together ControlCenter, MagicDraw UML, etc., which are entirely written in Java. As compared to other languages on the client side such as Perl, Python, Tcl, and others, Java proves to be a much more popular, proven, and practical solution. Java deserves to be distributed on every desktop built by OEMs especially if targeted toward enterprise.
Actually, yes, it is client-side applications...
>Shirky decries Microsoft's decision to debundle
>its JVM from Windows XP, calling it a "terrible
>blow."
While we are in agreement that the decision to remove an aging JVM that was largely acting to hold back Java development to standards set years ago isn't a "terrible blow" we have very different ideas about what should happen in response to it.
You think nothing, I think OEMs and everybody else should start including a modern JVM as a matter of routine.
>In fact, it's nothing of the sort. What right
>does Java have more than Perl, Python or Tcl
>to be bundled in with Windows? It certainly
>isn't client-side applications
Actually, yes, it _is_ client-side applications. While Perl and Python have been quite content being used from the command line and via browser based interfaces, Java has not.
Java has an excellent and sophisticated set of functionality for designing graphical UIs. It also has a set of 2D functionality that is probably sufficient to design almost any graphical program you might want to construct (e.g. a sophisticated paint or vector illustration program). If you don't believe me, check out the output from the Java based Batik SVG renderer (http://xml.apache.org).
Although you can make some noises about Tcl often being paired with Tk to offer similar cross-platform functionality I think you would be hard pressed to show me any large commercial applications written in Tcl/Tk and shipping today with the sophistication of JEdit, Forte/Netbeans, JBuilder, or PVCS.
Then pair GUI sophistication with the abilities of Sun's Java Network Launching Protocol (Sun's Java Web Start is a reference implementation of a JNLP launcher) and you can create applications like my own HotSheet that download, install and run with a single click on a single link in the browser by the end user. Successive runs of the same application will also automatically update when updates are made available. That's the kind of technology that end users _really_ need. I need to be able to tell someone, "Go to this website and click on the install link and you'll have the program you need. No muss, no fuss." That kind of simplicity is unavailable elsewhere and I as a developer don't even have to concern myself with the user's OS if he/she is using any of the usual consumer OSes (i.e. Linux, Windows, or Mac OS X).
But, all that is only true if I can be sure that my end users have a recent JVM installed on their machine and some form of JNLP launcher with it. So it's the ability to develop an application like that and serve the end consumer that makes Java have more of a right to be bundled in than Perl, Python, or Tcl.
On the contrary
In terms of the applications listed, shouldn't the installer for each of these apps determine if the jre is already installed, and if not, install it for the user?
It's no different then VB apps that need the vb runtime dll's - how many times have vb developers wished that Microsoft include the latest verison with windows. To get around this, they include the dll's with their install packages.
In terms of the enterprise/corporate apps, to ensure best results, you would still end up installing the jre on each machine to ensure the correct version.
In terms of applets, I think the responsibility is on Sun to make it seemless and easy to install. Same applies to acrobat for pdf files, winamp for mp3 files, etc.
As a sidenote, all of the apps you listed - Borland JBuilder, Sun Forte, TogetherSoft Together ControlCenter, MagicDraw UML - are used by developers, who should be smart enough to figure out how to install the jdk.
Millions of Consumers depend on browser JVM
You've asked " What right does Java have more than Perl, Python or Tcl to be bundled in with Windows"?
The answer is yes. Java has more right. Because Java is not just a language, but a platform to build internet applications specifically for browser applications. None of the above mentioned languages can run their applications in browsers, they merely run on server side. On the other hand, java applets run inside browser. And millions of consumers unknowingly depend on those applets for their day to day use. Not convinced?... Let me show you my posting in response to the open letter you mentioned:
Its a big blunder by Microsoft to exclude java from Windows. There're millions of people using thousands of java applets which depend on JAVA VM either in browser or JVM. If JVM isn't shipped with PC, everyday users of these apps will have the worst eXperience. In fact, these poor consumer normally don't know that they need java to use these applications. They just logon to a website and just start using it. They won't know what've happened to them when they buy their new PC (thinking that they're going to get some new experience), but will get the worst experience. It won't be fair to those consumers if Java is not shipped with every new PC sold.
Following are some of the examples of the Java apps being used (Note that these are the sites who've thousands of users logging on to their sites daily, on the other hand, their're thousands of other apps of limited scope too.):
1) Almost all of the stock tickers/analysis. eg
http://www.smartmoney.com/eqsnaps/index.cfm?story=charting&symbol=INTC&fk=3646
http://finance.yahoo.com/ (Java Manager)
2) Online games:
http://games.yahoo.com/
http://www.playsite.com
http://www.freearcade.com
http://www.javagameplay.com
3) Net Telephony:
http://www.dialpad.com
http://www.go2call.com
http://www.e001.com
4) Chat and Instant Messaging:
http://chat.yahoo.com
http://javatalk.excite.com
http://jpage.yahoo.com/jpager/messenger.html
http://www.aol.com/aim/aimexpress.html
5) News Tickers:
http://my.yahoo.com/javaticker/index.html
6) Live Poetry:
http://www.poetryandperformance.org/cp.hello.html
7) Education:
Lots and lots and applets have been developed to assist in different educational fields.
Some of the links of such applets:
http://dmoz.org/Science/Physics/Education/Java_Applets/
http://dmoz.org/Science/Math/Education/Java_Applets/
Ghulam Sarwar
Even Microsoft needs the JVM
My company is using Microsoft Exchange Server 5.5 for an email server. A lot of us connect up to it remotely by using Microsoft's Web Outlook client. This client uses Java applets to view the calendar. Now maybe Microsoft has removed this dependency on Java in its latest Exchange Server, I don't know, because there is no compelling reason for us to upgrade.
I disagree with the petition above. Java has great client side application support. The GUI framework is better than the Windows API. I know because I have been a developer on Windows since the 1.x days.
My company is developing a Java-based commercial productivity application. It runs fine under Windows and Linux without any code changes made to it. My whole team is a set of seasoned Windows developers and now none of us want to go back to the old ways. Our productivity has increased massively and the quality of the code is great.
It is a joke that Microsoft says that Java is code that no one ever uses. Like Microsoft applications don’t have any useless code in them!!
Java is good no matter what Microsoft says.
JVM
A message here recommends that people shipping software install Java, like they do the VB runtime. If anyone remembers the early attempts at that, with "commdlg.dll" and "vbrun*.dll" installing from multiple packages, and one package preventing another from running, they wouldn't even suggest such a thing.
There is a case for Sun to simplify installation and for developers to link to the download, like they do for other plugins like Flash. For yes, folks, Java is a plugin, and has been for a while. Anyone who's attempted to run Java applets that specifically need the MS or Sun JVM, and who's been thwarted by audio-related problems due to the presence or otherwise of sun.audio libraries will know that the promise of seamless integration of Java applets is a pipe-dream.
Maybe there's a case to let Sun own Java again, and to get them to worry about cross-platform and versions. Sun can then ensure auto-updates and backward compatibility, while we simply worry about getting the app to work on Java.
Call me paranoid, though - I still don't think I'd trust Sun to manage the above, and I wouldn't trust M$ to allow the JVM access to all the required OS functions in order to work properly.