> 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.
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…
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.