On the evolution of the Java plugin

; Date: Thu Jun 26 2008

Tags: Java

(web.archive.org) Ted Neward on the demise of Java applets is an interesting look back in history (interview on the Sparkling Client podcast). The Java Applet was the first of the RIA platforms, long before Flash became the king of RIA, long before Silverlight was a sparkle in anybody's eye, long before DHTML and AJAX became suitable as a rich internet applications platform, the Java applet was there. But Ted is quoted saying that Applet's suffered from incompatibilities and then they became frozen in time.

My post last august, (web.archive.org) Java is doomed to failure went over some of the history, that blog title came from a 1997 CNET article predicting the death of Java due to a proliferation of incompatibilities.

It's not quite correct to say that the Plugin itself was frozen in time. But that's not to say the plugin experience was not frozen in time. I'm listening to the podcast and what Ted really said was the JVM shipped by Microsoft was frozen in time due to the wranglings of Sun/MS lawsuit. Yeah, okay, and I can see how that would have constrained application authors in that they had to assume the majority of their users were on internet explorer w/ the MS JVM frozen at 1.1.4.

Applet's certainly didn't play out the way they were originally portrayed. There was this long strange road which we traveled with Java and Ted gives an interesting take on that history. The Client side of Java was clearly not given as high priority for many years as the Server side. I do like what Ted quoted in this podcast, that HTML in a web browser was equivalent to a 3270 terminal with fancy graphics. You youngsters may not understand the reference, but the 3270 terminal paradigm by IBM was..ah..primitive.. and the HTTP request paradigm is very similar.

However the plugin itself continued to receive bug fixes, performance improvements, etc. However we even have seen the light and (web.archive.org) Java 6 update 10 includes a completely rewritten Plugin which offers amazing new featureitis. And then there's that little thing named (web.archive.org) Java FX ...

Should we, as Ted suggest in the podcast, relegate Java to the server?? That's a hard one to determine which is the best answer. Clearly however we intend to have success in the client space with Java FX. And there is this little fact that the "Client space" is much more than browsers on a desktop computer. Java is deeply entrenched in the cellphone market and there is this rise of interesting new mobile devices with more power that can make for a rich internet explerience, and which are not desktops running a browser.

It's clearly going to be interesting to watch this unfold over the coming years.

In the meantime I thought it would be useful to link these two articles from 1997 which go over the nitty gritty details of the incompatibilities in the Microsoft JVM. It seems every time I post about the MSJVM it draws people who think Microsoft was unfairly portrayed ... just look (web.archive.org) at the comments on my earlier post, but the fact is that Microsoft did ship an incompatible JVM.

(web.archive.org) Microsoft sheds its Java skin

(web.archive.org) How to avoid potential pitfalls of Microsoft's non-standard SDK for Java

Source: (web.archive.org) weblogs.java.net

About the Author(s)

David Herron : David Herron is a writer and software engineer focusing on the wise use of technology. He is especially interested in clean energy technologies like solar power, wind power, and electric cars. David worked for nearly 30 years in Silicon Valley on software ranging from electronic mail systems, to video streaming, to the Java programming language, and has published several books on Node.js programming and electric vehicles.