 |
All Things Web Start - Web Start Paradise - Web Start Encyclopedia - Web Start Tools |
|
|
||
| What's On? | Web Start News | Web Start F.A.Q. | Web Start Forum | The Saturn Times | Web Start Services | Web Start Links | Download | Lopica @ Sourceforge |
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 the lopica-talk mailinglist (Subscribe/Unsubscribe) or or send a private email to gerald@vamphq.com (Gerald Bauer) 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.
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.
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.
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
Please, send your name and country to the lopica-talk mailinglist (Subscribe/Unsubscribe) or send a private email to gerald@vamphq.com (Gerald Bauer) and I will add you to the list of supporters. You can pick and choose and add also your own items.
| Please send comments on our web pages to our public lopica-talk mailinglist or to a member of our web team. | Copyright © 2001, 2002, 2003, 2004, 2005 The Lopica Team | |