Sophie Net: Vamp HQ - Luxor XUL - Rachel - Apollo - The Saturn Times - The Richmond Post
vamphq.com Logo
All the tools to deliver rich, cross-plattform, zero-admin desktop apps built on open standards today
About
OverviewFront Page
What's NewHistory As It Happens
Upcoming EventsWhere Do I Go Tommorrow?
ScreenshotsPictures, Pictures, Pictures
TestimonialsWhat Users Say About Vamp
CreditsThanks, Thanks, Thanks
ContactAre You Real? - Ich Spreche Deutsch
Site MapFind It Quick
Projects
Vamp StudioPackage, Sign and Publish Your App
Package ManagerCreate and Share Your Own CD App Collections
App CentralFind the Best Apps On The Web
JNLP ValidatorDTD, XML Schema, Relax
jnlp2htmlCreate Your Own App Catalog
Web Start Cache ExplorerUnder the Hood: Web Start's Cache Revealed
Web Start Cache UtilityInject Your App Into Web Start's Cache
Ant Task SuiteAutomate, Automate, Automate
vampgetGrab Apps for Offline Consumption
CD App InstallerCreate Your Own Single-Jar, Offline Installer
CD App Installer IICreate Your Onw Self-Executing, Single-Jar Installer
CD Installer MissionGreat Things Are Coming
Download
BinariesGet It Now
DocumentationPDF Booklets, Presentations
Support
DiscussionAsk Questions
FAQAnswer, Answers, Answers
Professional Services
InfoHire Me - Yes, I'm Available
Web Start
Web Start LinksEverything to Get Started
Unofficial FAQAnswers, Answers, Answers
JNLP Tag Quick ReferenceQuick Reference to Tags and Attributes
JNLP Tag ReferenceAll Tags Explained, Real-World Examples
Configuration ReferenceHand-tune Web Start's configuration (jawaws.cfg); all config settings explained
Offline Installer TutorialCreate Offline, No-Java, High-Speed Installer for Web Start under Windows
Installation ResourcesCreate Your Own Java Runtime Plus Web Start Installer
os and arch CollectionLinux, Windows, Mac, Solaris
Java 2 Runtime DirectoryLinux, Windows, Mac, Solaris
Web Start 2.0If I Were King
Print Version Print Version

If I Were King: Making Java Web Start Stronger and Ready for Prime Time

Note, this page has moved and now lives at http://lopica.sourceforge.net/king.html. Please click on the new address and update any bookmarks you might have.

Java Web Start 2.0 Petition

Java Web Start is a great product and Sun made a wise choice to start with a small core instead of a Big Bang that supposedly solves all the problems that a bunch of engineers locked up in California can imagine. Growing Java Web Start based on real-world experience and demands instead of pretenting to know-it-all has my full support and I am ready to give away my perls of wisdom for free.

What follows are my proposals for making Java Web Start better and ready for prime time. I invite you to underwrite this petition if you support my proposals as it is less likely that Sun will ignore it. Please, send your name and country to comments@vamphq.com and I will add you to the list of supporters. Your comments are also welcome as I don't pretend to know-it-all either.

Table of Contents

Side-by-Side Excecution - Avoiding DLL Hell

Today it might be hard to imagine that your Java Web Start app cache is overflowing with tons of Java applications as they seem harder to find than oil in Texas. However, I believe that one day your app cache will be buzzing with Java apps. This might happen sooner than you might think.

To avoid what is known in the Windows world as DLL hell I propose to allow multiple versions of the same resource to live in the Java Web Start application cache. This avoids that applications that rely on shared resources mysteriously break down because somehow another application has replaced the jar with a newer version that is no longer compatible with an older version or an older version has replaced a newer version and isn't forward compatible (how could it be?).

This is not a hypothecial case that is less likely to occur than an alien showing up at your door, but instead this case is highly likely once you consider that the only proven strategy to improve your productivity is through reusing someone else's code through shared libraries. Fortunately, DLL hell will be less severe in the Java Web Start universe than in today's Windows world. However, that's no excuse to lean back and play Whack-A-Bill. In the pre-.Net Windows world all shared libraries are squeezed into a single directory leading to a Gordian knot that denies users access to their apps. Java Web Start is smarter as resources that share the same base name (e.g. venus.jar) can peacefully coexit as long as their URLs differ (e.g. http://www.nasa.org/planet/venus.jar vs http://www.olympus.gr/godess/venus.jar).

Assuming that all shared jars will be backward compatible forever is naiv, idealistic, wishfull thinking as progress depends on change and that means that from time to time shared jars will have to break with backward compatiblility. Shared jars won't break overnight, but if you start thinking in years instead of milliseconds change will be inevitable and, therefore, it would be foresight to be prepared.

Believe it or not .Net solved DLL hell in the Windows world with what is known as side-by-side execution to insiders. Side-by-side execution allows different versions of the same dll to coexist peacefully at the same time in the global assembly cache. This clearly shows that I can be done even though the approach surely needs to be adopted for Java Web Start.

Cache API

The Java Web Start Cache is the holy grail of Java Web Start everyone will try to get a hand on as it has great potential to lock you in so that you can be milked for money. What user would give up all her apps in the cache just for trying out a different Java Web Start brand? Just daring souls, I guess.

Multiple JNLP clients (aka Java Web Start brands) should be able to peacefully coexit. The miracle could be achieved through a mandatory Cache API that gives you full read and write access to the cache.

For a start, it would be great if Sun would open-source and donate their cache implementation for Java Web Start to Apache or a similar organization to help foster the growth of tools that are needed to make Java Web Start ready for prime time.

Using a Cache API, for example, would make it fairly easy to create a tool that upgrades all apps in the cache at once. The tool could be scheduled to upgrade all apps on the user's behalf daily after midnight without supervision on a locked-down desktop, for example. This method would be superior to what some sadistic vendors propose today. They would rather prefer to let users watch the real-time, live upgrade in a cermony in the morning with everyone else upgrading at the same time so that they can charge you $25,000 per application for a clustering server that breaks down under the workload anyway and if you complain you will be told that it's time to buy a closed-source JNLP client that supports checkpointing, bandwith throttling and more for just $300 per seat.

This is just a simple scenario on how a Cache API would make users happier as their apps would be groomed nightly and be ready for a turbo launch in mere seconds in the morning. Companies could save bundles by distributing the upgrade workload over twelve hours instead of beefing up the server for an insane fifteen minute workload explosion once a day and letting millions of MIPS idle away the rest of the day in search for extraterrestrial civilizations.

Make the Command Line Work

If you type javaws -help or javaws -? nothing will be revealed. Java Web Start evidently doesn't have any command line options yet, but it should.

If you try to launch a previously downloaded application that allows offline usage by typing javaws http://jakarta.apache.org/ant/antidote.jnlp when you are offline and the web server is unreachable, the launching will fail even though it shouldn't as everything is in the cache right in front of you. What's the point of an offline tag, if you can't launch applications when you are offline?

Surprisingly, however, if you use the mangled name and type javaws file:///c:/java/jws/v101/.javaws/cache/http/Djakarta.apache.org/P80/DMant/AMantidote.jnlp, Java Web Start launches the app successfully even when you are offline and the web server is unreachable.

Suppose you start a treasured app twenty times a day. How likely is it that the application was updated in the mean time assuming a standard release cycle of eighteen month? Zero. Trying to connect to a web server on the other side of the planet to find out what is already self-evident is a waste of time. Therefore, Java Web Start should have a command line switch that lets you turn off up-to-date checking and instead immediately turbo charges your app from the cache. Example:

javaws -offline http://jakarta.apache.org/ant/antidote.jnlp
Signatures - List of Supporters

Please, send your name and country to comments@vamphq.com and I will add you to the list of supporters. You can pick and choose and add also your own items.

  • Gerald Bauer, Austria
  • John Munsch, USA (Cache API only plus additional items, see comments for details)
  • Jean-Baptiste Bugeaud, France (plus additional items, see comments for details)
  • Silvia Tsai, Taiwan
  • Guillaume Desnoix, France
  • Mic Wolter, The Netherlands
  • Joe Walp, USA (plus additional items, see comments for details)
  • Mike Rarick (plus additional items, see comments for details)
  • Jonny Boman, Finland
  • Christopher Burkey, (plus additional items, see comments for details)
  • Amar Syed, United Kingdom
  • Gianni Barberi, Italy
  • Farley Caesar, Canada
  • Nick Gusev, USA (plus additional items, see comments for details)
  • Sven Haiges, Germany
  • Suprit Chaudhary, see comments
  • Zahid Patel, see comments
  • David Harvey, USA

All the tools to deliver rich, cross-plattform, zero-admin desktop apps built on open standards today
vamphq.com Logo
Send your comments, suggestions or praise to webmistress@vamphq.com Copyright © 2001, 2002 Gerald Bauer