Migrating Away from Applets: Why WebStart Was Our Bridge

Posted on By Luis Fernandez

We just moved our biggest app off applets and onto Java Web Start, and I want to capture the why while it is fresh. The browser keeps changing under our feet. IE still rules on desktops, Firefox keeps sneaking into developer machines, and everyone is excited about Ajax after Google Maps taught the web a new trick. The old Java plugin is still the same moody roommate. Signed dialog here, classloader quirk there, and a fresh batch of users with a different minor JRE update. We needed something steadier. WebStart became our bridge. Not a destination forever. A bridge that let us keep Swing, push updates fast, and calm down support calls.

Context

Right now the desktop is mostly Windows XP with locked down policies. Corporate proxies add strange rules. Some folks stay on Java 1.4 since their ERP says so. Others get 1.5 through the Sun updater and do not know it. Applets inside pages meant we had to fight the plugin on every page load. Different browsers. Mixed caches. Weird focus bugs. People love to right click and print and save files locally. Applets can do it if you sign all the jars and juggle permissions, but then you get the scary yellow dialog. Every release becomes a round of phone calls. Our team needed fewer moving parts at launch time.

At the same time, Ajax got good enough for a lot of UI. But we still needed heavyweight features like local files, fast charting, printing without acrobat gymnastics, and some offline usage for sales reps on planes. Flash and Flex look nice, but rebuilding our codebase in ActionScript was not an option. GWT looks promising but is still new. WebStart let us ship a desktop grade app through a link without forcing a traditional installer. That was the pitch.

Definitions

  • Applet: A Java program that runs inside the browser via the Java plugin. Lives in the page. Shares the JavaScript wall with LiveConnect when you are brave.
  • Java Web Start: A launcher that pulls your jars from a URL, caches them, and starts your app as a desktop process. The file that points to your app is a JNLP descriptor.
  • JNLP: An XML file that lists resources, the main class to run, permissions, icons, and what JRE you want. The browser downloads it and hands it to javaws.
  • Signed jars: Jars signed with a code signing certificate so users see your name and you can request permissions outside the sandbox like file access and printing.
  • Auto update: WebStart checks the server for newer jars and only downloads changed bits. You get versioned rollouts without asking users to reinstall.
  • Offline: If you mark it so, users can create desktop shortcuts and launch the app without a network. The cache handles it until the next check.

Examples: how we moved from applet to WebStart

Our starting point was a big signed applet that rendered a complex Swing UI. It needed a large download on first use, and the plugin sometimes lost its mind on minor updates. We cut the cord by doing three things.

  • Gave the app a proper main(). Instead of an Applet subclass, we created a launcher class that sets up the same UI in a JFrame. For a while we kept an Applet adapter so we could run side by side during transition.
  • Wrote a clean JNLP. One file to rule the jars, the JRE version, and the permissions.
  • Fixed the server. We served the right MIME type for JNLP and jars so browsers would hand things to javaws without weird downloads.

Minimal launcher

public final class ClientLauncher {
    public static void main(String[] args) {
        javax.swing.SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                // Your former Applet UI now in a JFrame
                javax.swing.JFrame frame = new javax.swing.JFrame("Reports");
                frame.setDefaultCloseOperation(javax.swing.JFrame.EXIT_ON_CLOSE);
                frame.setSize(900, 650);

                // Reuse existing panels and controllers
                frame.setContentPane(new ReportsPanel());

                frame.setLocationRelativeTo(null);
                frame.setVisible(true);
            }
        });
    }
}

JNLP template

<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+" codebase="https://example.com/client" href="client.jnlp">
  <information>
    <title>Reports Client</title>
    <vendor>Acme Corp</vendor>
    <description>Rich reporting client with offline support</description>
    <icon href="icons/reports.png"/>
    <offline-allowed/>
  </information>

  <security>
    <all-permissions/>
  </security>

  <resources>
    <j2se version="1.5+"
          initial-heap-size="64m"
          max-heap-size="256m"/>

    <jar href="reports-client.jar" main="true"/>
    <jar href="libs/commons-io.jar"/>
    <jar href="libs/looks.jar"/>
  </resources>

  <application-desc main-class="com.acme.reports.ClientLauncher">
    <argument>--env=prod</argument>
  </application-desc>
</jnlp>

We signed every jar with the same certificate. Mixed signatures trigger ugly prompts that spook users. We also shrank jars and used pack200 on the server to speed the first launch for Java 1.5 users.

Server config for JNLP

Browsers must know what to do with JNLP. On Apache we added this line.

# httpd.conf or .htaccess
AddType application/x-java-jnlp-file .jnlp

On IIS we mapped the .jnlp extension to application slash x dash java dash jnlp dash file in the MIME types list. Yes it is a mouthful. It works.

Useful commands

# Open Web Start cache viewer
javaws -viewer

# Clear a single app by URL if a bad cache sticks
javaws -uninstall https://example.com/client/client.jnlp

# Launch from a JNLP saved to disk
javaws client.jnlp

With this setup our users click a link, accept our publisher once, and get a desktop shortcut. Updates roll out the next time we publish new jars. Support calls dropped.

Counterexamples: where WebStart is the wrong tool

  • Tiny inline widgets: If you only need a date picker inside the page, Ajax wins. Pulling a JRE for that is like bringing a truck to carry a postcard.
  • No JRE allowed: Some locked desktops block Java entirely or stay on 1.4 with company policies you cannot change. WebStart will not save you there.
  • Hard JavaScript integration: If the app must talk to the page with live JS events, applets still fit better than round trips to a separate process. Or stick with pure Ajax.
  • Mac and Linux quirks: Our Windows audience is the majority. On other platforms you may hit older Java builds where WebStart support is flaky. Test on those.
  • Thick media or fancy animation: Flash or Flex will probably beat you on polish and load time for pure media apps.

There is also ClickOnce on the Microsoft side. If you are all in on .NET and Windows, that path can be smoother for those users. Our code was already in Java, so WebStart made sense.

Decision rubric: choose applet, WebStart, or something else

  • Runtime control: Do you need a specific JRE and memory settings. WebStart lets you pick the JRE version and heap upfront. Applets borrow whatever plugin the browser has.
  • First time install: Can your users install Java. If not, do not choose Java anything. If yes, is the initial download size acceptable given your audience and network.
  • UI surface: Does the app fill the screen and behave like a desktop tool with menus, drag, and local shortcuts. WebStart feels natural there. If it is a small control in a page, use Ajax or Flash.
  • Permissions: Need file system, printers, or native calls. Both applets and WebStart can get permissions with signed jars. WebStart shows fewer surprises and makes shortcuts easy.
  • Offline mode: Required. WebStart wins. Applets are tied to the page. Ajax is online by nature.
  • Update cadence: Do you push frequent releases. WebStart incremental updates are painless. Applet cache issues mutate into bugs that are hard to reproduce.
  • Corporate proxies: Heavy proxies can break applets inside pages more often than a direct WebStart fetch. Still test both.
  • Integration with page: If tight LiveConnect with JavaScript is core, applets have the edge. Otherwise decouple.
  • Team skills and code reuse: You already have Swing. Moving to WebStart is mostly packaging. Moving to Flex or pure Ajax means a rewrite.

Our weighting looked like this. We cared about offline and local files. We wanted control of JRE and memory for our reports engine. We did not need to embed inside a portal page anymore. That tipped us toward WebStart.

Gotchas we hit and how we fixed them

  • Mixed signatures: One library was unsigned and triggered a generic publisher warning. We signed every jar with the same certificate and the dialog showed our company name once.
  • JNLP MIME type: Without the right MIME on IIS, IE tried to download the file instead of launch it. Adding the MIME type fixed it for everyone.
  • Cache ghosts: A few users had old jars stuck. The cache viewer and uninstall command cleared it. We also bumped jar versions in the JNLP to force refresh.
  • Memory settings: Reports needed more heap than the default. JNLP j2se element let us set max heap cleanly. No more java plugin command line hacks.
  • Class path order: Applets used to load our jars in a certain order by accident. JNLP makes the order explicit. Once set, bugs vanished.

SEO friendly checklist for your own migration

  • Java Web Start JNLP basics: Build a clean JNLP with title, vendor, description, icons, j2se version, and application desc. Keep jars small and versioned.
  • Signed jars and permissions: Use one code signing cert across all jars. Request all permissions only if you need them.
  • JNLP MIME type on server: Apache AddType line or IIS mapping to application slash x dash java dash jnlp dash file.
  • Auto update and offline support: Mark offline allowed if you want desktop shortcuts. Test updates with version bumps.
  • From applet to main class: Replace Applet init with a main method that builds the same UI in a JFrame. Keep an adapter for a double life if you must.
  • Test against proxies and locked desktops: Try a clean non admin Windows account behind a proxy. Check log output from javaws console.

Lesson learned

Web tech trends are loud. Today everyone talks about Ajax toolkits, and new ones seem to drop every week. Our real pain was not that the applet was uncool. The pain was predictability. Who owns the runtime. When do users see a warning. Can we update without clearing caches. Can we ship a shortcut that works on Monday morning after a Sunday deploy.

WebStart gave us a stable middle ground. We kept our Java code and Swing UI. We stopped debugging plugin fails on each browser minor release. Users got a desktop app that launches from a link. Deploys became a publish and verify routine. We still use Ajax for the lighter stuff in the portal. The heavy client moved out of the page and life got calmer.

Will we stay here forever. Maybe not. The browser keeps getting stronger. When the day comes that a pure web app can handle our offline needs and file access without scaring users, we will move again. For now this is the right trade. Migrating away from applets toward Java Web Start was our bridge and it bought us time to focus on the product instead of the plugin.

One last tip. Keep your first launch experience tight. Use pack200 on the server for Java 1.5 clients. Sign once. Trim jars. Put your JNLP on a fast CDN if you have one. Measure cold start and warm start. Nothing beats a smooth first click when you are asking users to try something new.

If you are on the fence, run a spike. Wrap your app with a main method, write a tiny JNLP, and hand it to a colleague in accounting. Watch them click. If they end up inside your app with a shortcut on the desktop and no call to support, you have your answer.

Digital Transformation Software Engineering