Java Web Start

~ the obit ~

half of turkish enterprise software in the 2003-2010 window had a.jnlp file in it somewhere. java web start was how that file actually opened an application. i ran into it constantly during the computer engineering years. the banking client for one of the turkish banks was a swing application launched through web start, and the e-government portal had a couple of forms that opened a signed jnlp for smart card authentication.

the protocol shipped with java 2 standard edition 1.4 in march 2001. sun positioned it as the answer to the question that java applets had been trying and failing to answer for five years, how do you let a user run a real desktop java application from a link on a web page. applets ran inside the browser inside a sandbox with severe ui limits. web start downloaded the same bytecode bundle but ran it as a normal desktop process. the application got its own window and its own jvm, and it could ask for file system access through a manifest declaration.

the.jnlp file itself was a small xml document. it pointed to a set of jar urls and declared the security level the application needed. the jvm fetched the jars, cached them against the signed manifest, then ran the application as a desktop process. updates worked through a version check on launch, the new jars would replace the cached ones. it was the closest thing to a desktop app store that existed in 2003.

~ the rap sheet ~

~ how it landed ~

enterprise IT loved web start because it solved the deployment problem on every platform that java ran on. a swing application shipped through jnlp would run identically on windows and linux, the user did not need a fresh installer or an admin password past the first launch. for internal corporate clients this was a clean answer. every major bank in europe had at least one jnlp-launched application by 2007, a lot of brokerage and trading platforms shipped that way.

the consumer side never really happened. web start required a recent jvm installed on the local machine, which was a problem for ordinary windows users who would not survive a jre version mismatch dialog. the signing requirements got stricter every year as the jvm sandbox attracted more exploits. by 2012 the chrome browser was actively warning users away from any link that pointed to a jnlp. the consumer use case had effectively died by then but the enterprise install base kept going.

~ the long retirement ~

oracle started signaling that web start was on the chopping block around 2015. the npapi plugin api that java applets depended on got pulled from chrome in 2015 and from firefox in 2017, which removed the entire applet category and made web start the last surviving way to launch java from a browser link. oracle filed jep 289 to deprecate the browser plugin in jdk 9 and jep 198 to remove it. java web start went with the same modular cleanup, removed from openjdk 11 in late 2017 and from the oracle commercial jdk 11 release on september 25 2018.

~ what came after ~

the organizations that depended on web start mostly moved to openwebstart, a karakun-supported reimplementation built on top of icedtea-web, the older open-source rewrite from redhat and adoptopenjdk. it parses the same jnlp files and runs against modern jvms, shipped as a standalone installer for the holdouts. the protocol is technically alive, the oracle implementation is not. java applets ([[java-applets]]) went the same way a year earlier, the whole browser-plugin world they came from is in the same museum as [[activex]] and [[microsoft-silverlight]].

@}-->--

              )
             (_)
            .-'-.
            |   |
            |   |
            |   |
            |   |
          __|   |__   .-.
       .-'  |   |  `-:   :
      :     `---'     :-'
       `-._       _.-'
           '""""""

« previous  ·  random  ·  next »