Calvin Austin's Blog

Applets re-birth, what happened?

Dion was privy to some news about the latest news on Java Applets. But why a re-birth of applets and how did they get from front page news to an industry footnote?

My first experience of applets was from WebRunner, the Java based browser which spread through Sun like wildfire. I was working for Sun in Europe in those days and it was such a step up in ease of use for anyone who had to mess with motif or X before. In addition to webrunner, was the standalone appletviewer tool which allowed you to keep up with the ever changing api.

However applets were dependent on Motif for Unix, something that didn't change until JDK 5 and Sun didn't have a lot of development history with Windows either. The apis was functional but new, there were many early issues with modal dialogs and later motif related drag and drop issues in 1.2

The big push was for Java 1.0 and of course the adoption by netscape, however deployment of 1.1 applets was immediately affected by the pace of netscape development and the infamous reverse dns lookup feature. For applet developers it meant that many complex early applets would 'break' because they were too new or fell foul of corporate firewalls.

At the same time there was a push to JavaBeans and the getter/setter pattern was applied to awt in a frenzied rush. This resulted in the large batch of deprecated methods event from 1.0 that many Java developers still lament about today.

However momentum was building, Microsoft was a licensee by this stage and Project Swing was the next big thing. Anyone who worked on awt was immediately moved to Project Swing. Swing was very comprehensive, but obviously larger. It introduced the new event model and brought many other library features. It also required JDK 1.1 and didn't become part of the platform until J2SE 1.2.

By now the hotjava browser was losing adoption and Java was totally dependent on the browser plugin apis. Displaying the output of a separate process into a browser as a plugin does was still an impressive technical feat but consumers are more interested in it just working. What was really needed were the plugin and browser teams to work as one but due to many very public reasons that never happened.

So could applets rise again, of course. It requires the browser teams to be onboard and a significant investment in engineering and testing

As with any re-collection I've tried to summarize many events to the best of my ability so any errors are not intentional and corrections are welcome

Comments

• Sorry for my english: From 10 years ago, to Now: 1. We coded local apps with local databases (with awt, you know...) 2. next - We coded local apps with remote databases in 2 tier (with awt, swing, etc...) 3. next - We coded local apps downloadable vía web (Applets) (with awt,...) 4. next - We coded remote web apps with remote databases in 3 tier by using html, web frameworks (call it spring, struts, whatever) , just because all browsers seemed to use standard html & javascript 5. next - We coded with code based framework for web (instead of html, return to use AWT-like source code, call it ECHO2 or wingS, or Flex, or JavaFX) and remote Databases accesed in 3 tier with SOA, just because, hey!, not all browsers use standard html & javascript. 6. next - We go back to Applets, just because we noticed that, after all, we are coders and code applications, not demoscene, and we are feared by the next Firefox X or IE X coming out in one month and our application in danger. 7. Next time, we will go back to 2 tier (Application to SOA) downloadable software, and get ride of web browsers. It seems like if we were walking in circles looking for something we dont know, and doing frameworks meanwile... Daniel Rodriguez Developer

  Posted by: soynegativo on October 24, 2007 at 01:22 AM

• Here is my accounting, following soynegativo's model: 1) (JDK 1.0 to early 1.1) Using AWT for trivial apps 2) (late JDK 1.1) Using AWT or Swing to build front-ends, with most back-ends still written in C++, using CORBA ORBs to integrate both (we were big CORBA users and pushers at that time) 3) (early Java2) Same as before, but now writing the back-ends in Java, with either CORBA or RMI as middleware. Start using Servlet and JSP technology as clients start demanding more web-based UIs, and Swing on JDK 1.2.x was a pain 4) (J2SE 1.3) Last Swing-based GUIs created at my company. At this time, post-Merlin, Swing looked good enough to bet, and we build some very large and sophisticated GUIs - admin stuff that only a few users with good machines would run, so the footprint was not an issue. But that was a sort of last song of the swan. 5) (J2SE 1.4+) Only web-based UIs, with J2EE technology and also Struts and other tools. Swing development relegated to maintenance/survival of legacy codebases since that time; not a single full new project used Swing here - not at my company, not anywhere I go in outsourcing projects etc. Swing is dead as far as I can see. In my country (Brazil), the status of Swing is even worse because, compared to the US, computers are more expensive and people use them longer. Right now I guess American developers can target entry-level dual core CPUs (e.g. Intel 1,86GHz) as the high-end desktops are already moving to quad-core. But I must shoot a full generation lower: I'm happy if all my clients have at least a early (Willamette family) Pentium-IV, with 256-512Mb of RAM. So, Java rocks in the server - datacenters have powerful machines anywhere in the world - but it's a dead duck on clients, which already struggle to run WinXP, IE7 and the full load of crapware that corporate desktops are always running (like Outlook or Notes, antivirus, etc.). IMHO, Java as a rich-client platform has yet to recover from Swing's disastrous architectural decisions, remarkably thin components - which basically means: "adding a huge layer of Java libraries to duplicate work that's already performed very well by the OS, and doing that MUCH worse than the OS". Now Sun is promising to fix the latest performance problems in UpdateN, e.g. full D3D acceleration and preloading for better cold starts, but the footprint problem is not being addressed, in fact it only gets worse. The latest cool stuff is JavaFX, which at least in the current implementation for Java SE, is yet another layer on top of Swing. Today the SwingSet2 demo consumes ~60Mb of RAM (working set size); an FX version would probably move to 100Mb. Earth to Sun: The roughly equivalent ControlExample demo of SWT 3.3.1 runs on 15Mb, not to mention much better loading time, performance and LAF.

  Posted by: opinali on October 24, 2007 at 06:26 AM

• Calvin,

  What ever did happen to the idea of the Java-based-browser?

  My problems with applets had mainly to do with interactions between HTML/JavaScript in the Browser and the Java in the Applet.... If only the HTML/Javascript renderer had been inside my applet, things might have been much more manageable.

  -JohnR

  Posted by: johnreynolds on October 24, 2007 at 09:24 AM

• I see one recurring theme. The people who could make JavaFX successful in one area are the same folks who probably got burnt by applets so far.

  The java based browser, hotjava, Essentially the 10 or so people it couldn't keep up with netscapes whole division but more on that later

  Posted by: calvinaustin on October 24, 2007 at 11:07 AM

• You didn't mention the real reason why applets became a footnote.

  They didn't deliver what was promised. It's that simple. They didn't deliver. There was this huge hype around Java, and Sun doing all sorts of promises. And there were applets. Horrible download and startup times on the networks and computers available to the average user in that days. Reality and the promises from Sun just didn't match.

  Once a year someone close to Sun announces the return of applets. It didn't happen the last x times it was postulated. It is unlikely it will happen this time. Applets are dead.

  Regarding hotjava. I think the common rumor is that the strange javax.swing.text package and javax.swing.text.* packages hold some remains of hotjava. And that the reason why the classes in these packages don't follow the normal Swing communication model is their descendence from hotjava.

  Posted by: twe on October 25, 2007 at 03:29 AM

• JohnR, there is a project to make HotJava available. Access to the source would have been very useful to me at various times over the past several years, so I've lobbied various Sun employees to release it. Josh, graciously agreed to own the project to do so. We've been waiting on approval to release the code for just shy of 3 years.

  Posted by: coxcu on October 25, 2007 at 07:32 AM

• If you would to see a recent real world usage of Java plug-in and Java live-connect, you should check out the NeuroKernel, a next generation Client/Server platform from NeuroDNA Computer. http://www.neurodna.com/

  Posted by: jasuha1 on January 15, 2008 at 06:42 AM

This work is licensed under a Creative Commons License.