News and commentary from the cross-platform scripting community.
|
||
|
RE: JAVA JAVA JAVA | |
Sent: 5/21/96; 5:40:52 PM
From: amd@cs.brown.edu (Adam Doppelt)
Hi. You probably don't remember me, but we've spoken a couple of times. Once about Java. I read today's piece and thought I'd send a few comments.
Re: Java Java Java
One of the questions you ask is why people want or need Java. The answer first given to us by Sun and Netscape was multimedia. Interactive, streaming multimedia applets were supposed to dominate web pages at this point, supplementing traditional pages. Not surprisingly, artists and developers have had great difficulty bending Java's infant libraries to the task. It appears that Shockwave will be the tool of choice for people wanting to spice up their pages with a little animation and sound.
However, Shockwave is ill suited to handle dynamic information. Taking data in one form and transforming it to another has long been the job of scripting languages. It might be argued that cgi scripts can fulfill this need, but programmers are already hitting the limits of cgi's push and pull nature. I think that search engines and elaborate hacks such as PixelSite are about as far as cgis can take us.
Some people are already trying to use Java to dynamically relay information. MapQuest has an applet which blows away their cgi"interactive atlas". I saw an applet the other day which would rebroadcast a baseball game inside an applet, letting you watch either games in progress or archived games. Gamelan will let you see how many users are hitting their web server as the seconds tick by. The bottom line is that Java is being used to construct highly specialized data viewers, replacing the clunky cgis which have sprung up in the past couple of years.
You also touched upon the fact that you haven't seen any truly compelling applets, and that the long download time and slow execution speed made you want to avoid them entirely. I believe these problems are related.
Developers like Java as a language, but aren't happy with the current implementation. Many people point to the lack of mature, stable development tools, but that isn't the real problem. Although we love products like CodeWarrior and Visual Basic, programmers have survived with shoddy or nonexistent environments in the past.
The real problem lies in the Java runtime shell. As you pointed out, applets take a long time to download. Some applets need to hit a web server dozens of times before they are fully assembled. And once an applet has loaded, it might run slowly or not at all. Not to mention the developer's nightmare of a "cross-platform" language which runs a little differently under each platform.
These problems are (by their very nature) temporary. They are implementation flaws, not technology flaws. Sun has cooked up a scheme to load many classes with a single hit, which should vastly improve startup time. Integrate Java's zip file class loader with Netscape's URL fetcher, and applets should appear almost as fast as images. And if Sun doesn't release a more speedy and stable runtime environment, Microsoft (and hopefully Apple) surely will. I've already heard reports of huge performance improvements using Microsoft's runtime shell inside of Internet Explorer. Competition and market demand will cure these ills. All we have to do is wait.
Unfortunately, many developers find it difficult or impossible to create workable applets using today's Java. Pop up menus? A monumental task. Threads? Fine, just don't resize the browser. Personally, I'm amazed at the applets which have been developed despite these difficulties. As the runtime execution improves, inventive programmers will continue to show us what Java is (and isn't) good for.
Adam
-------------------------------------------------------------------
Adam Doppelt http://www.cs.brown.edu/people/amd amd@cs.brown.edu -------------------------------------------------------------------
- targets - today's problems - solutions