Although developing rich user interfaces is the topic de jour for many Java Web developers, applets, the original Java UI technology, are seldom mentioned as a viable mechanism for that purpose. The idea and implementation behind applets did not change much in the thirteen years since Duke's bouncing figure heralded Java.
The biggest change to applet technology had to wait until this year. Sun managed to cloud one of the more significant news items during JavaOne 2008 with the simultaneous focus on JavaFX. While JavaFX is more about the future, Sun has already delivered on important changes to how applets work in the latest JRE update. A recent Sun Developer Network article, Next Generation in Applet Java Plug-in Technology by Dana Nourie, introduces the new features:
The most significant new feature of the next-generation Java Plug-in is built-in support for launching applets from JNLP files. Using the JNLP file format as the applet descriptor allows applets to instantly reuse JNLP extensions previously written for Java Web Start applications, and significantly expands the capabilities of applets in many other ways...
The applet behaves exactly like an application started with Java Web Start software..
In addition, applets have now much more control over the VMs they execute in:
Applets no longer execute in a Java Virtual Machine (JVM) inside the web browser. Instead, a separate JVM machine process is launched to execute applets. By default, only one JVM machine is launched, but you have the opportunity to launch more than one JVM machine, and you get support [for] per-applet command-line arguments, so you can affect heap size or other requests...
There is a small, headless JVM inside the browser that is used to manage the connections to one or more client JVMs that actually run the applets...
Because applets now use the JNLP infrastructure and configuration, they have access to the entire JNLP API and capabilities, such as PersistenceService and DownloadService, and can control their VM's heap size, version, and command-line arguments.
New applet features also address usability issues, such as:
The new plug-in also offers better customization of the image, which is displayed before the applet is loaded. Animated GIFs are now supported as the target of the image parameter...
A forthcoming feature, available as an early-access preview, will also let users drag an applet from a Web page to the desktop, effectively installing the applet as a desktop application.
What do you think about the future of applets as a rich-client technology?
This is interesting considering all the hype around "new" client side technologies such as Goggle's GWT. Personally, I find GWT and similar JavaScript-based thick client frameworks a perverted mess. They are at best confining. More accurately I'd say they're a piss poor approximation of a real presentation manager exposed to a real language. Yes, I'm saying it. The emperor has no clothes. JavaScript is pop art. Don't take my word for it, the very existence of GWT establishes that even *Google* finds JavaScript so intolerable they opted to write a toolkit so we could avoid looking at it altogether. But GWT is still what it is - smoke and mirrors.
What is the point of writing a thick client app targeting JavaScript and Html? Really. Applets at least give you a respectable presentation and windowing framework, a rich set of libraries, and a real OOP langauge.
Don't get me wrong. I'm not advocating thick client apps. I'm merely pointing out what should be obvious comparing JavaScript-based thick client frameworks vs. Java ones.
> New applet features also address usability issues, such > as: > > The new plug-in also offers better customization of the > image, which is displayed before the applet is loaded. > Animated GIFs are now supported as the target of the image > parameter...
That's an UNusability feature in my book. Yet one more thing for epileptics to avoid like the plague. And, yes, "rich" interfaces are a plague. :-( Come on, developers, please avoid needless animation and slipping, sliding, swooping, GUIs.
Perhaps Java and operating systems should have a user preference which can disable such effects or just disable those that haven't been tested for suitability.
There is a system available which can check video for its risk of triggering a seizure.
Also there are probably quite a few epileptics who rather like these effects.
Previous Topic
