Java Web Start - Popularity

Question

I recently used a Java Web Start application. I launched it from my web browser using an embedded jnlp link in the page I was viewing. The application was downloaded, launched and worked just fine. It had access to my local file-system and remembered my preferences between restarting it.

What I want to know is why are Java Web Start applications not a more popular delivery format for complex applications on the web? Why do developers often spend considerable time & energy replicating desktop functionality in html/javascript when the power of a desktop application could be delivered more easily using Java & Java Web Start?

I know that in some corporate environments, e.g banking, they are relatively popular ways of delivering complex trading applications to clients, but why are they not pervasive across the web as a whole?

(For the sake of discussion let's assume a world where: download sources are "trusted" & applications are "signed" (i.e. no security concerns), download speeds are fast (load time is quick) and developers know Java (in the numbers they know html/js/php)).

Mcelhaney

I love the idea that there are no security concerns with signed applications. – Corruption

Answer 1

I think the reason is not security nor startup time of the app. Let's understand what's behind the scene before we find out the root cause.

Java Control Panel has settings that allow users to use the default browser's proxy settings or to override them. In other words, infrastructure teams are able to customize the Windows or OS installation images to have JVM pre-installed with enterprise proxy settings. So I believe this is not an issue at all.

Java Web Start actually caches all apps with customizable settings in Java Control Panel. Once the app is cached, the app is "installed" just like other apps. Although first time execution may be slow, the second time will be fast due to JVM's smart memory allocation technique. So start up time could be an issue but a lot of web sites (even enterprise internal) are now migrated to portal. A web portal normally contains lots of unused libraries for development purposes due to the fact that the portal itself does not anticipate what kinds of portlets are built and deployed on a specific page. Therefore, downloading a single portal page could consume up to MBs and complete a page in more than 5 seconds; this is only one page and caching helps up to 30% but there are still lots of HTML/Javascript/CSS components required to download every time. With this, I am sure Java Web Start is an advantage here.

Java Web Start does not download again if it is cached as long as the server copy is NOT upgraded. Therefore, if, e.g. a project management software like MS Project, is completed using SmartClient (similar to JWS), the information exchange between the client and server would be purely data without presentation like browser's full page refresh. Even with the help of Ajax, it doesn't eliminate full page download entirely. Besides, a lot of companies consider Ajax to be immature and unsecured still. That is why Ajax is a hot topic in the circles of developers but not within enterprise software yet. With that in mind, JWS apps definitely have more advantages such as how JWS apps are deployed and executed in sandboxes, signed, and have much more interactive GUI.

Other advantages include faster development (easier to debug in code and performance), responsive user interface (does not require Comet Servers to provide PUSH functionality), and executing faster (for sure because client computers renders GUI without translation like HTML/Javascript/CSS, and less data processing).

After all these, I haven't touched the question yet, why JWS is not so famous?

My opinion is that it is the same as Brian Knoblauch's comment, it's without awareness.

IT folks are too attracted by the hype of Web Technologies, Ajax PUSH, GWT, and all those buzz words make them bias towards the fun of using different technologies or to resolve technical challenges instead of what's really working for the clients.

Take a look at Citrix. I think Citrix is actually a great idea. Citrix allows you to build your own app farms behind the scene. There are tons of upgrade and implementation strategies you can go for without impact to client experience. Citrix deployment is extremely easy, stable and secure. Enterprises are still using it. However, I think JWS is even better than Citrix. The idea of JWS is to run apps on client machines instead of hosting tons of server farms where client machines are capable of running these apps themselves. This saves a company a lot of money!!! With JWS, development team can still build business logic and data on server side. However, without the web processing unit and let the client computers do the rendering process, it greatly reduces the amount of network consumption and server processing power.

Another example of why JWS is an amazing idea is Blackberry MDS. Blackberry apps are actually Java apps translated from Javascript. With BB's MDS studio, you use the GUI tool to build BB app GUI, coding GUI logic in Javascript. Then apps are then translated and deployed on a BES server. Then the BES server will distribute these apps to BB. On each BB, it runs a thin Java App with GUI rendering and networking capability only. Whenever the app requires data, it communicates with the BES through web services to consume services from other servers. Isn't this just JWS BB version? It's been extremely successful.

Finally I think JWS is not popular because of how Sun advertises it. BB never advertises how good their BB Java apps are, they believe clients won't even care what is it. BB advertises the benefits of using MDS to develop apps: Fast, Cost Saving, Business Return.

Just my, a bit long, 2 cents... :)

Agility

This is a purely theoretical answer. Surely, JWS looks great on paper, but it is simply not production ready. – Robers

JWS is officially dead now. See JDK 11 Release Notes – Ideational

Answer 2

A major roadblock for Java Webstart is probably that you still need to have a JVM installed before it can even attempt to download and start your application. Everyone has a browser. Not everyone has a JVM.

Edit: I've since acquired some hands-on webstart experience and can now add these two points:

• The Deployment Toolkit script and the modularized JVM released somewhere around Java 1.6u10 make the JVM requirement less problematic since it can automatically download a JVM and the API core and start the program wile downloading the rest.
• Web Start is seriously buggy. Even among the Java 1.6 releases there was one which downloaded the entire app every time, and another which downloaded it and then failed with an obscure error message. All in all, I cannot really recommend relying on such a fragile system.

Proper

but presumably the hurdle of installing a jre can be made as painless as that of installing flash or any other browser plugin? – Mcelhaney

The JRE is still a lot bigger than those (Java6u10 introduced measures to alleviate this), and it doesn't come preinstalled with Windows (which I believe Flash does). – Proper

+1. This is related to my question: #3380684 – Rhombencephalon

everyone has at least 3 different browsers to display few different rich client web apps correctly... and 5 developers constantly have some work to do on each of them because new browser version is on the go – Cityscape

...and yeah, it is rarely the case, but it happens that some big companies limit their stuff to use that single ugly browser from Microsoft because they want to finally get rid to spand money on all those compatibility issues – Cityscape

Answer 3

I think it's mostly due to a lack of awareness. It works very well. Quite seamless. App only downloads if it's the first time, there's been an upgrade, or if the end-user has cleared the cache. Great way to deploy full-blown desktop apps that user won't have to worry about manually upgrading!

Teapot

I agree, and I think if JNLP had been created earlier in Java's history we would probably see a stronger Java presence on the desktop. – Medwin

Since this answer I've run across a couple of problems. JNLP's caching system has a critical design flaw. If 2 copies of the same JNLP app are run, and the source has changed between the launch of the 1st and 2nd, the execution results of the 1st are unpredictable. Instead of downloading a second copy and running that, JNLP dumps the new version over top the old and starts the second copy. This horrifically breaks the first copy. Next fault. Self-signed certs are now deprecated. Fine for web use, but really hurts Enterprise developers. – Teapot

Do you mean two copies with different names or two copies of exactly the same code base with the same name, but using different browsers? And yes, deprecating self-signed certs stinks, but there is a work-around for enterprise. You could install a self-signed cert as trusted and then it should function the same as one issued by an "authority." – Medwin

Neither. 2 copies of the exact same application from within the same browser, but the codebase has changed between the first and the second copy launch. Browser wouldn't matter anyways though, it's the JNLP cache itself that doesn't handle this (common for us) case properly. – Teapot

Answer 4

The problem with Webstart is, that you actually have to 'start' something which isn't at all that fast even with a fast connection, while with a webapp you enter the URL and the app is there.

Also a lot of things can go wrong with webstart. Maybe the intended user doesn't have the privileges needed, or the proxy of webstart is configured wrong, or something went wrong with jre dependencies or there is simply no java installed in the first place. So for the average john doe in the internet it is not at all pleasent.

In controlled environments like a company it is a good and easy solution in many cases.

Cataclysm

I see what you mean about "starting", but given that we assumed that download speeds were fast, how is this any different at all than "starting" a webpage by "clicking" on a link? It's the same thing, surely, i.e. a link on a page. – Mcelhaney

Unless there's been an upgrade, it starts fast the second time due to caching. – Teapot

I tried to clarify in the answer: even on a local network webstart is considerably slower then a typical web app – Cataclysm

What's a typical webapp? I'm not talking about replicating the funcitonality of a simple webpage but rather an entire application. Once your java app has loaded the cost of going from "feature" to "feature" is much less than the equivalent if it had been created using a series of webpages. – Mcelhaney

True, with equal amount of features Webstart is: much slower on first start,probably slower on following start ups, easier to develop and debug, faster at runtime. But the question wasn't about pro and cons of webstart but about the cons (real or conceived) – Cataclysm

Web Start should be able to start the local copy "instantly" and then say "hey there is an update, want to download it?". If the user accepts then the user can keep working and when the whole set of new jars havebeen downloaded the next time the application starts the new jars are used. – Lamar

@Brian Knoblauch, "fast" is relative. It is not fast enough that Sun doesn't need a splash screen... – Lamar

On the machines I've used it's plenty fast. The slow part is the splash screen... :-) The splash screen is advertising, not something to keep you occupied while it loads. – Teapot

Answer 5

I've worked on a JWS-deployed application for a few years over a user base of a few thousands and its automatic upgrades are actually a huge pain.

On every update for some reason dozens of users get "stuck in the middle". All you get is the "class not found" exception (if you're lucky), or uninformative "unable to launch" from JWS before it even gets to your code. Looks like the update is half-downloaded. Or, in other words, it does not download and apply the update atomically AND has poor caching so that relaunching the app from the same URL does not fix anything.

There's no way to resolve it other than clearing JWS cache or providing a different URL (e.g. append ?dummyparam=jwssucks at the end). Even I as a developer hit it sometimes and don't see a way around.

When it works, it works. But too often it doesn't, and then it's a huge pain for you and your helpdesk. I would not recommend it for enterprise or mission-critical use.

Soundboard

What version of Java were you using? – Dustproof

6 and up to date. Still a mess as of now. – Soundboard

Wow, what a pain. I haven't seen that thankfully. I wonder if setting the update check to "background" would help. This way it can download the latest version while the current version is running. – Medwin

Answer 6

There is a very big issue namely that it doesn't allow for "start the program instantly and THEN check for and download any updates in the background" deployments, which is what the defacto behaviour of applications are converging to.

I consider this personally so big an annoyance that we are actively looking for another technology which provides that.

Perigee

That would be a good option to give to the person deploying it. I wouldn't make it totally an end-user decision though. The developer would have to turn the option on to allow the use that choice. In my particular environment, we need to force (no user choice) upgrades at start time. – Teapot

Java Web Start does have this capability. Put <update check="background" policy="prompt-update"> just before your <resources> section. – Rhombencephalon

Sounds like some of the new functionality introduced with the Java 6 revision. Does this work for the main jar, too. – Lamar

Yes it works for the main jar. I think it is exactly what you were looking for. – Medwin

Answer 7

From these posts it looks like when using Web start, it is important to make a good care about the server. The "huge pain" of downloading application on every startup may be caused by incorrect time stamp delivered from the server. Here not the application but the server must be configured to use caching properly and not just to disable it. About buggy start, I am not that much sure, but it seems to me that this also may be caused by unreliable connection.

Important advantage of Web start is that it works nicely with OpenJDK under Linux. Clients of some happy developers use Windows only but my clients do not.

HTML and JavaScript, mentioned in the initial question, are lighter approaches that work fine with smaller tasks like animated buttons or even interactive tables. Java niche seems around much more complex tasks.

Robeson

Answer 8

Java Web Start is kind a successor of Java Applets, and applets got burned around the new millenium. But, I still think Java Applets are way better than GWT or Javascript hell.

Java Web Start vs Embedded Java Applet

Decomposed