DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > A Better Java Webstart for Standalone Apps

A Better Java Webstart for Standalone Apps

Michael Schnell user avatar by
Michael Schnell
·
Mar. 03, 11 · Java Zone · Interview
Like (0)
Save
Tweet
10.12K Views

Join the DZone community and get the full member experience.

Join For Free

Webstart is a nice solution for deploying Java applications. But when it comes to a corporate environment, it has a not-so-small problem: The Java Runtime System itself.

If several applications share the same Runtime, you may get into version trouble—Some applications want to have the latest Java version to fix some bugs. Other applications don’t want to update because they fear incompatibilities. Or there is simply no budget for regression testing all applications with a new Java version.

Some of you may argue against it because Java has claimed to be always backward compatible—But believe me, that’s not true. I took part in three version updates 1.3=>1.4=>1.6 and there were always changes in the behavior of the UI that need to be addressed!

In my opinion, an optimal Java (standalone) application is simply copied into a local directory and has its own Java Runtime inside this directory. That way, it can be easily removed by simply deleting the directory, and it no side effects occur with different JRE versions or with the OS environment in which it’s running.

But how do we update such an installation? We simply use Webstart as a kind of Bootstrap Loader!

The process should be as follows:

  1. Start a generic updater with Webstart.
  2. The updater refreshes all changed JAR files of your application. This includes the JRE itself that lives inside the application directory.
  3. Finally, the updater starts your application using the local Java Runtime.

 

That way you have best of both worlds: The updater itself is updated with the standard Webstart mechanism, and your application runs completely independent from the environment. A nice surplus is that you no longer need to sign your JAR files because the main program is no longer a Webstart application (only the Generic Updater needs to be signed).

Java (programming language) application

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • SQL Database Schema: Beginner’s Guide (With Examples)
  • 8 Must-Have Project Reports You Can Use Today
  • How to Build a Simple CLI With Oclif
  • Caching Across Layers in Software Architecture

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo