Smeltet has posted 3 posts at DZone. View Full User Profile

When Will Java Web Start be Production Quality?

01.19.2010
| 11432 views |
  • submit to reddit

Java Web Start (JWS) has always had great potential. With this deployment platform I can reach users such as mom-and-pops who would otherwise have to call their son (me) when they need to download and install something from the internet. Mom-and-pops are not that interested in computers but they know how to write an email and click a link on a webpage. To start a JWS application all they have to do is click a link on a webpage. While the application is being launched it is also cached locally. It can be started offline and updates are detected and installed automatically. The installation does not require much interaction or even awareness that something is being installed unless:

  • JavaSE is missing – in which case it will be installed automatically before the application is launched but dialogs are abundant.
  • The application requires permission to do stuff outside the normal security sandbox – in which case a security dialog is shown.

The latter dialog may actually deter mom-and-pops from starting the application but despite this I consider their chances of successfully starting a JWS application to be far greater than that of a native windows application.

A few months ago i revisited JWS but sadly reaffirmed my impression from years back that JWS is not production quality. Many features have been implemented in fashion that I can only describe as “strange”, the documentation is a mess and central features are bug ridden.

Glossing over the release notes for JavaSE 6 update 18 today my eyes caught a number of fixes for JWS. Particularly the fix for a bug I reported myself 6888118: “JNLP Extension Installer is never invoked when uninstalling application“. Uninstalling a JWS application on windows is supposedly simple. The user navigates to the same place in the windows Control Panel where native applications are uninstalled, finds the JWS application and hits “uninstall”. Unfortunately JWS has been broken and would only uninstall some parts of the application – in some cases leaving the user with a system that would complain again and again that the remaining pieces of the application was crashing. Pretty awful bug for such a “mature” system – who dares install this “java stuff” from the net on their PC if it can’t be uninstalled? I hope to test this fix soon.

And oh yea the offline launch of cached applications was broken 6800992. If the webserver was down you couldnt launch the application even though the application was right there on your local system and it was configured to allow offline launch. I built a fairly complicated solution to this problem. I can’t go back to vanilla JNLP if I want to support all those users with a broken version of Java 6.

Another real awful one was this 6863499. The automatic update of jars didn’t work unless your JNLP file that describe the application was simple.

One strange design of JNLP was the requirement of a codebase href inside the JNLP file. Its looks like its now optional for the common case 6866509.

I’m happy that many critical bugs have been addressed but some of them are regression bugs. So with these fixed, what has been broken now? Alright thats a bit pessimistic, I really want to use JWS and I hope update 18 will turn out to have production quality! :)

Here are the release notes for JavaSE 6 update 18. I recommend this feed to follow the Java SE 6 updates.

From: http://scalemania.wordpress.com/2010/01/14/when-will-java-web-start-be-production-quality/

References
Published at DZone with permission of its author, Smeltet Kerne. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Piotr Kochanski replied on Tue, 2010/01/19 - 4:35am

Nice post, I have been wondering why so few people use technology with such a potential, now I know...

Glen Haneman replied on Tue, 2010/01/19 - 6:05am

It seems that with every new version, they fix some bugs but reintroduce others and some are real showstoppers. I've wondered just how much regression testing Sun's webstart developers do to allow such critical bugs to go unnoticed. Even now, with 6u18, I'm seeing some strange things that were not there in 6u17. Each time I start an app when no updates are needed, I see the webstart downloading/launching window flash up for a split second. And this is with Sun's own swing tutorial demos.

I like the idea behind webstart and I do use it to deploy apps, but it's given me plenty of grief and I'm always looking for better alternatives.

Osvaldo Doederlein replied on Tue, 2010/01/19 - 6:24am

The new factor, now, is that Sun is finally eating their Java Desktop dogfood, with JavaFX and the Java Store. If Sun(Oracle) plans to have ANY chance of success, they'd better fix once and for all at least all important deployment issues, for both applets and JAWS. 6u18 indeed looks like another big improvement; as for the regressions, I can understand it because 6u10 was such a massive feature update so it was bound to have some important regressions. But time's up, 2010 will be the "make it or break it" year. In a few months, there will be no more excuses left: the Oracle takeover will be complete (and they will either invest heavily in Java Client/RIA technologies... or not); at least two major JavaFX updates will have shipped; JavaStore FCS will have shipped; a couple great design tools for JavaFX will have shipped; the last batch of JavaME (MIDP 3.0 / LWUIT / JavaFX Mobile) will find their way into many consumer devices (...or not); finally, JDK 7 will be shipping. If all this stuff is well executed, I think the prospects are pretty good. If they aren't, or (worse) if they are but still Java fails to regain any significant midshare, this will be game over - world won't wait for the next round of promises due 2011. Exciting times ahead...

Greg Brown replied on Tue, 2010/01/19 - 10:28am

Couldn't agree more. I really want to be able to use Web Start as a means for delivering client applications, but it is still much too painful for the end user.

Casper Bang replied on Tue, 2010/01/19 - 10:48am

I made the mistake in the past of believing it was already production ready. The problems I ran into:
  • It WILL fail on a percentage of machines for whatever reason (cleaning cache and installing a full JRE usually helps)
  • Watch out when updating security certificate of signed JAR's, it's usually safest to give users a whole new URL.
  • Very hard to relocate an existing application URL (JWS does not follow redirects)

In short, it's promising but just watch out... Sun is not exactly known for following through 100% and the deployment story is no exception.

Carl Antaki replied on Tue, 2010/01/19 - 11:15am

I also tried to use it for my Facebook application Bloom but it failed. Sometimes it would cache a Jar and it wouldn't update it.

I now only use it for Linux and Solaris deployment and I change the main Jar name every time, I also change the splash screen name so I'm sure it's not cached.

JWS is good in theory but slow in practice. I also found that the JNLP ClassLoader uses more memory than a traditional classloader.

The best deployment option for a platform is to deploy the same way as native applications, i.e. msi for Windows and dmg for Mac and that's what I use. Even though these bugs have been fixed in Java 6 Update 18 how long will it take for the average Joe to get it? On Mac Java 6 Update 18 is not available and on average it takes around 2 years for most people to get it. So JWS is a no/no for me for now.

Jakob Jenkov replied on Tue, 2010/01/19 - 3:03pm

I skipped Web Start a long time ago... one major issue is not taken care of: Software Licenses related to Software Updates. Not all users may have a license allowing them to update to the new version. I ended up writing a small application updater myself, which uses SWT. It would run before the application, and update any JAR files, other files, and show any relevant messages from me to the user. It looks much better than Web Start too.

Otengi Miloskov replied on Tue, 2010/01/19 - 3:49pm

For desktop development I will skip complete all the Java/JWS/etc or Even C#/WPF. The BEST for desktop native applications development is to use C++/Qt and for deployment as someone said MSI for Windows, DMG for Mac and tar for Linux.

It is sad to said but Java et al it is a server side tech and always will be.

Michael Parmeley replied on Tue, 2010/01/19 - 5:12pm

My team has been using Java webstart to deploy desktop applications to clients over the public internet for many years. I don't recall every having any painful times with it.

 

I have never had a problem with it refusing to update a jar.

 

The security dialog is somewhat annoying, but hardly a blocker.

Pete Cox replied on Tue, 2010/01/19 - 5:25pm

When Sun open the code - They've been murmuring for a while now about contributing the code to openjdk.

Red Hat couldn't wait, so they've developed replacements in icedtea. But that still leaves users stuck with the 'official' JRE out in the cold...

Piotr Likus replied on Wed, 2010/01/20 - 4:52am

Good question, I had serious problems with using Java Web Start 7 years ago... Now it is still not usable??

Problems was with documentation which was so inaccurate that even missleading.

 At least now JWS starts correctly some JavaFx demo programs...

It should be one of most important technologies in Java world - from user point of view.

But it seams that for Sun it isn't...

 

Smeltet Kerne replied on Wed, 2010/01/20 - 6:21am in response to: Piotr Likus

 

>It should be one of most important technologies in Java world - from >user point of view.

>But it seams that for Sun it isn't...

 

Yea its strange that Sun doesn't realize the value of JWS. They often boast how Java is deployed on millions of desktops across the world. By contrast you and I cannot hope to persuade that number of users to install our homegrown deployment framework for Java applications - we depend on a big player such as Sun. 

JWS makes a big difference in user experience. JWS installation and launch is not only smoother than that of native applications it also gives the user the safety of running the application in a security sandbox. Installing a native application often entails choosing a location on disk, restarting windows, finding the relevant entries in the menu system to start the application. Being a technically minded person its easy to overlook that even one of those steps is enough to put off mom-and-pops users. Software developers are a minority on the web - we should build applications for mom-and-pops.

 

Dirk Lemmermann replied on Wed, 2010/01/20 - 11:43am

JWS not only has bugs but it is also missing features. I tried to implement a more advanced login dialog, one that would not only allow users to login, but also to retrieve their password, or to register (when using the app the first time). Read more in this blog article.

Elvis Yea replied on Thu, 2010/01/21 - 4:19pm

It will be ready for production just after the very last person comes to their senses and stops using Java for client side development. The problem is Sun simply don't understand end users, they understand techies, but not end users and seem to look down on users that were unable to get it working. Spend some time on some of the forums and the attitude of the Sun developers says it all. They're extremely defensive and ignore or dismiss valid suggestion if they consider it criticism. While they now seem to be spending more energy on client side Java they still don't get it. For example they spent a significant amount of time on a recent feature that allow users to drag an applet outside the browser, who cares? Fix the bugs first!!! Or the new streamlined install process!? it's a bit better but it still seems as if it doesn't really want you to install it. Webstart itself is simply the most irritating piece of technology I've ever used. As it happens I spent most of today trying to locate another obscure bug. I've wasted the last 7 years developing client Java in the misguided hope that Sun might actually improve Applet or Webstart. I've recently started using Flex and I wish to God I'd done it years ago. My only hope for all our client side Java code is that Oracle buy them and kick them into shape by replacing the people on the client side Java team, because unless the lead people there are replaced I can't see things improving fast enough to even keep pace with Flash/Flex, let alone catch it up. Sorry to write such a negative post.

Johan Compagner replied on Thu, 2010/01/28 - 8:24am

i am not sure yet, but it seems 6u18 has broken a lot for us.

 We use signing and have a few signed jars for our application. When we upgrade or system not all jars are updates (if the signing certificate stays the same). But the core jars are. Now it seems that i have jar X,Y and Z and in an update X,Y are updated and downloaded again but Z didnt change so webstart leaves it as is.

Now when i access something in Z i get a signing error! But they are signed with the same thing, thats not changed. This always worked before u18

 When i clear the cache and let webstart redownload the complete application then it works fine..

anybody else encountered something like this?

Johan Compagner replied on Thu, 2010/01/28 - 11:35am

i tested some more, i always through that signing jars also made sure that that code cant be altered with, but this is not really true.

 i can just go to the cache dir of javaws and then alter a jar file that is signed by updating an existing class, this class will be run just fine. I cant create new classes but if i can just alter existing classes inside a jar, how can i then know if that is secure. Because signing not only says to the downloader of the application that it is secure, but also for me as the one with the application on the server wants to make sure that the downloader (or another not so nice person) will not tamper or cant tamper with the code he gets from me. 

 i always thought that signing classes would result in also taking the hash (and size) or something from the class file. Then it could in theory also go wrong if somebody could  exactly reproduce the hash and size of the class but that is way more difficult then what he can do now.

Mark O'donohue replied on Fri, 2010/02/05 - 5:23pm

 

Hi

 Wasnt sure if you got there, but we have problems with how to uninstall webstart apps,  Control panel Add/Remvoe programs does not workbut you can remove them with :

        javaws -uninstall 

        javaws -uninstall  http://<url>/startup.jnlp

 

I appreciate the Control Panel/Add Remove Programs should auto call those, but in case anyone else is like us swearing and trting to find out how to remove them - thats how its done.

Cheers - Mark

Sindy Loreal replied on Sat, 2012/02/25 - 8:19am

I do agree with you.
It’s been so long for Sun to take care of all those “version 0.0 problems”.
If now many issues around jnlp are fixed, and also that java virtual machine is fast enough…. well it’s day 1 for java embeded in Web pages.

Day one for a technology that is (I think) 5 years old, how odd is that !

Passion Lab replied on Tue, 2012/08/14 - 2:08pm

Positive site, where did u come up with the information on this posting?I have read a few of the articles on your website now, and I really like your style. Thanks a million and please keep up the effective work. Forex Programming

Sadia Sulaman replied on Mon, 2014/04/21 - 3:35am

 I am happy to find your distinguished way of writing the post. Now you make it easy for me to understand and implement the concept.

www.BlogHuts.com

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.