> Nobody likes updating Java, and we couldn’t risk having strange behaviours caused by an outdated JVM > The application is built on top of the open source version of Google Chrome, i.e. Chromium

So instead of updating Java, we now have an ecosystem where everyone and their dog are shipping their own bundled Chrom(e|ium) instead, which surely is not going to cause even more upgrade-related problems in the future.

> So instead of updating Java, we now have an ecosystem where everyone and their dog are shipping their own bundled Chrom(e|ium) instead, which surely is not going to cause even more upgrade-related problems in the future.

And each install wastes an impressive amount of space.

I won't call 120 MB (total weight of our app, including assets) an impressive amount of space. Also consider it's something people will use for work purposes, an unique configuration tool instead of having 3 or 4 small tools to configure each single meter type.

Errata corrige: 84 MB. 120 was the debug build!

I get your point here, but since the bundled Chromium version is compiled by ourselves we do not rely on an external toolset, allowing us to support just one version at a time. If you're intrested, we use Sparkle (http://sparkle-project.org/) to deliver remote software updates.

> allowing us to support just one version at a time.

On the flipside, each program has to maintain the whole stack themselves, and have to push out security updates if necessary. I'm not sure this is an improvement over Java's security situation…

I see it like this: 1) let the user handle the security updates of the JVM; 2) push out security updates in a centralised, controlled fashion.

IMHO, in a corporate solution like that described in the OP, 2) makes a lot more sense.

didn't get your point honestly