Objections against Java Webstart?

Question

Since the release of Adobe AIR I am wondering why Java Web Start has not gained more attention in the past as to me it seems to be very similar, but web start is available for a much longer time.

Is it mainly because of bad marketing from Sun, or are there more technical concerns other than the need of having the right JVM installed? Do you have bad experiences using Web Start? If yes, which? What are you recommendations when using Web Start for distributing applications?

Answer 1

In my company we used Java Web Start to deploy Eclipse RCP applications. It was a pain to setup, but it works very well once in place. So the only recommendation I could make is to start small, to get the hang of it. Deploying one simple application first. Trying to deploy a complete product that is already made without experience with JWS gets complicated rather quickly.

Also, learning how to pass arguments to the JWS application was invaluable for debugging. Setting the Environment variable JAVAWS_VM_ARGS allows setting any arbitrary property to the Java Virtual machine. In my case:

-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=4144

Helpful when you need to check problems during start-up (suspend=y)

I think the main problem for the acceptance of Java Web Start is that it is relatively difficult to setup. Also, somehow there is this dissonance: When you have a desktop application, people expects a installer they can double click. When you have a web application, people expects they can use it right from the browser. Java Web Start is neither here not there...

It is widely used in intranets, though.

Answer 2

I work in the intranet of a Bank since 5 years, and my departament has developed and distributed a LOT of Java Web Start Applications which are used all arround the world, i think Java Web Start has the best of the Desktop applications (easy development, rich user interface, processing power in the client machine) and the Internet applications (easy deployment and upgrade).

I really like Java Web Start

Answer 3

I did a project once in JWS and it was a pain to get running. Worse yet, I wasn't even dealing with the entire Internet, it was a small application that only a few people in my office were going to use. I threw my hands up in disgust more than once while both configuring the server and helping them set up the application on the client machines.

I think AIR is now getting more popular (although I never know how far it will get) because it has applications that people actually want to use (name your favorite JWS app... go ahead, I'm waiting) like twhirl. I still am not a huge fan of the way AIR works but it's a hell of a lot better than JWS.

Answer 4

Here is a list from mindprob:

• Java Web Start applications are painfully slow to start. The monitor loads a fresh JVM for itself and for each application. Applications always check on the web for updates, downloading and processing an entire new JNLP file, rather than just checking its date. However, if it takes 80 seconds or so to check for a new version, it means you are likely having trouble with a proxy server. Start javaws.exe and click edit ⇒ Preferences ⇒ Network Settings ⇒ Direct. You don’t want JWS trying to use the Google Accelerator proxy. Also check in IE, click tools ⇒ Internet Options ⇒ Connections ⇒ LAN Settings and make sure all is as you expect.
• Updates take just about as long to download as the original application. There has been almost no cleverness applied to make the updates compact.
• It requires custom code running on the ISP to properly serve the jardiff files or to use the coming pack200 hyper compression.
• It has not changed much since its initial release. It may be yet another orphaned product. It does not deserve to be. However, Sun has released a new beta 1.2 after a year or so of nothing happening, and it has been integrated into the JRE, so we’ll see if it is picking up steam again. There are some major problems they have ignored, such as the certificate OK hiding behind the splash screen, and requiring ok for every jar separately. Even if it is orphaned nothing to terrible will happen. Unless you write unsigned JWS apps and use the JWS sandbox, your JWS apps will run fine standalone.
• It requires special configuring of the JNLP MIME type both at the ISP and in the client’s browser. Neither of these are under the developer’s direct control.
• If you have an urgent update, you can’t force it to be installed before the app is ever run again.
• It needs a rigid scheme to assign hard disk space on the client’s machine that has the following properties:
  • The names of the directories assigned must avoid name clashes with other vendors. They should incorporate the main package name of the application.
  • The names must be meaningful to the end user. They should be something he can remember, find and type when he needs to find files with desktop tools.
  • The scheme must provide a place both for per-user and per-application files.
  • A program should work on any platform without modification to deal with finding its files.

Answer 5

Java Web Start is the right way to start bigger Java applications because it allows for easy updating and installing/downloading the application and allows for better UI/UX than Java applets.

However, there are some roadblocks for launching Java Web Start applications from a web page using common browsers with default settings:

1. Sun/Oracle failed to create a working browser intergration. See http://crbug.com/10877 for example about Google Chrome / Chromium. Basically the Java plugin fails to implement the required NPAPI stuff to get Firefox and Chrome to reliably forward the MIME-type application/x-java-jnlp-file to javaws / javaws.exe binary.

2. Sun/Oracle failed to get a real registered MIME-type for Java Web Start .jnlp files. The application/x- prefix technically means draft or private.

3. Sun/Oracle failed to use URL scheme instead of MIME-type when the intent is that Java Web Start handles the application downloading and launching. For example, if instead of using URL such as https://example.com/app/launch.jnlp Java Web Start were launched as javaws://example.com/app/launch.jnlp things would work much smoother. This is because in this case, the web browser does not need to even load the .jnlp file, it just passes the full URL to the scheme handler (which would be the javaws binary).

Notice the repeating part ("Sun/Oracle failed ...") and you no longer need to wonder why Java Web Start never got much traction. The big missing part is getting a web page link to reliably launch the javaws binary with the given .jnlp file. That should be technically really easy (just register a new URL scheme when the javaws binary is installed), yet Sun/Oracle failed to do that. I personally think that the whole mess was caused by trying to mess with the MIME-type instead of simply using a new URL scheme. And even the MIME-type stuff was done really badly, for crying out loud.

If you still want to use Java Web Start, simply prepare good documentation for correctly configuring the browser to workaround the mess left by Sun/Oracle. The good part is that it's only needs to be done once and it will work for any site that uses Java Web start. The bad part is that usually the browser has never been configured to do the right thing with .jnlp files and you get the blame for using "hard to use technology" because users do not want to configure their browsers just to use your application. Did I mention that it was Sun/Oracle that failed to configure the browser automatically?

Answer 6

My experience:
I used it ca 2006, intranet application for a bank.

First download was fine, however when wanting to push out a new version, the caching of the jar files did not work, so the new files were not pushed to the client.

Spent a week trying to fix this without success.