# OpenWebStart: bringing Java Web Start back without picking a Java vendor

> OpenWebStart is a set of native installers that restore Java Web Start on modern Java releases, built on the IcedTea-Web core developed with the AdoptOpenJDK community. The project targets Java 8 LTS first, keeps the Web Start logic in a separate upstream repository, and is released under GPLv2 with exceptions.

**karakun/OpenWebStart** — Run Web Start based applications after the release of Java 11

- Repository: https://github.com/karakun/OpenWebStart
- Website: https://openwebstart.com
- Stars: 529 · Forks: 63
- Language: Java
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/karakun-openwebstart

## The problem is a removal, not a deprecation

OpenWebStart exists because of a specific event in the Java release history, and the README states the sequence plainly. Java Web Start was deprecated in Java 9, and starting with Java 11, Oracle removed JWS from their JDK distributions. The consequence for users is stated in one sentence: clients that have the latest version of Java installed can no longer use JWS-based applications. That is a harder break than a deprecation, because a deprecated feature still works while a removed one does not, and the removal was not accompanied by a replacement in the JDK. The second half of the problem compounds it. Public support of Java 8 ended in the second quarter of 2019, so companies no longer get any updates and security fixes for Java Web Start. That combination, a feature removed from the runtime and an old runtime no longer patched, is what left a large body of enterprise and internal applications without a launch path. OpenWebStart's answer is stated as offering a user-friendly installer to use Web Start and JNLP functionality with future Java versions without depending on a specific Java vendor or distribution. The project is Apache-licensed by no, the repository listing records a custom licence that GitHub cannot classify, and the README states the project is released as open source under GPLv2 with exceptions, so the licence file is the place to check what the exceptions allow.

## The division between this repository and IcedTea-Web

The most important structural fact about the repository is what it does not contain. The README is explicit: this repository contains all sources that are needed to build OpenWebStart releases based on the IcedTea-Web core functionality that is developed at the AdoptOpenJDK community. And it says so again at the end of the About section, saying that this repository only contains the sources that are needed to create enterprise-ready and user-friendly native installers. So the Web Start implementation itself lives elsewhere. It is developed in the IcedTea-Web repository of the AdoptOpenJDK organisation, together with Red Hat and other members of that community. This is the sort of arrangement that is common in the Java ecosystem, where the specification of a feature and the packaging of it for end users are maintained by different groups with different incentives. IcedTea-Web began as the open implementation of Web Start for distributions that wanted it after the Oracle deprecation, and OpenWebStart is the layer that turns that implementation into an installer a non-technical user can run on a machine with a modern Java. Reading the two projects separately is important for anyone contributing, since a change to the behaviour of Web Start belongs upstream and a change to how it is delivered belongs here. The homepage is openwebstart.com and the most recent release is v1.14.0 from 2026-07-06, before that v1.13.0 from 2025-12-01 and v1.12.0 from 2025-05-28.

## A vendor-independent approach, and why it matters to the installer

The stated philosophy is a Java vendor independent approach, and the README is careful about the distinction between the two things Karakun does. While they develop user-friendly installers to use a Java vendor independent approach for Web Start, they also help to integrate Web Start functionality in the Java 8 LTS releases of AdoptOpenJDK. Both halves point the same way. The first is that the installer is not tied to one Java distribution, which matters because the alternative to installing a new runtime is often to install a specific vendor's old runtime, and that reintroduces exactly the end-of-life problem the project exists to solve. The second is that the same feature set is also integrated into a mainstream distribution, in this case AdoptOpenJDK's Java 8 LTS builds, which means there are two routes to the same functionality and the installer route exists for the machines where the distribution route is not available. The project is developed by Karakun, who publish a developer site, and the repository carries a FUNDING.yml file, which is the mechanism platforms use to declare where sponsorship for the project can be routed. The first goal is stated as targeting Java 8 LTS versions while support for Java 11 LTS will come in near future, and the ordering is worth noting, since Java 8 is where the bulk of the legacy JNLP applications actually run and where the accumulated deployment experience sits.

## What is in the tree, and the shape of the build

The top level of the repository shows a Maven multi-module project with a few directories that are more specific than a typical Java project. There is an openwebstart/ directory, which is the main module. There is a download-server/ directory, which is the piece that serves the installer and its metadata to end users, and it is the only part of the tree that is inherently server side. There is a ManifestResourceTransformer/ directory, which in a project like this is about rewriting the manifest of a packaged artefact, and for an installer that carries an embedded runtime it is the piece that adjusts the bundled metadata. There is a system-properties-printer/ module, which reads like a diagnostic tool, the kind of small utility that helps a user or a support engineer report what the installed runtime thinks its configuration is, and that kind of module tends to be the one that ages best in an installer project since troubleshooting is a permanent need. There is a documentation/ directory, a readme/ directory holding the images referenced by the README, including the rocket illustration and the footer image, a pom.xml at the root, and a Maven wrapper in the form of mvnw and mvnw.cmd together with a .mvn/ directory, which is the standard way to pin the Maven version and settings for a build so that a contributor and a release machine use the same tool. There is a release.sh script at the root, an .editorconfig and a .gitignore, and the LICENSE.md file. The presence of a release script and a wrapper in the same tree says the build is meant to be reproducible from a fresh checkout on any platform, which is what you want from a project whose output is a binary that people install.

## The licence, and why the exceptions matter

The README is one sentence on the licence, that the project is released as open source under GPLv2 with exceptions, with a link to the LICENSE.md file, and the repository listing records the licence as a custom one that GitHub cannot classify. Both statements point at the same document and neither paraphrases it, which is the correct behaviour for a licence with exceptions, since the exceptions are the part that decides what a downstream user may do. The general shape is familiar. GPLv2 is a copyleft licence, so a distributor of a modified version has an obligation to convey the source, and the exceptions carve out specific additional permissions or carve specific things out of the obligations. For a project of this kind the exceptions are likely to address the packaging rather than the Web Start logic, since an installer that bundles or launches a Java runtime touches components with their own licences, and a project that wants to be widely redistributable needs to say plainly which obligations it waives. That is a document to read before you redistribute anything from this repository, and it is a document to read again if you plan to modify the installer rather than simply use it. The project also ships documentation/ and INSTALL.md as separate files at the root, so the installation instructions live alongside the licence rather than only inside the README.

## Where OpenWebStart is the wrong choice

The first limit is that this is a launch mechanism, not a migration. JNLP applications still have the properties that made them a problem in the first place, and reinstalling the launcher does not remove them. The application is still distributed as a desktop program over the network, the deployment still depends on the network path between the client and the server, and the security model of downloading and running code from a URL is the one Web Start was designed for and the one that later made it a target. A team that can move its applications to a browser launch or to a locally installed client removes the dependency entirely, and no installer improves on that. The second is the version targeting, where the first goal is Java 8 LTS and Java 11 support is described as coming in the near future, so a deployment that has already moved past those versions has to check what the current release actually supports before assuming it applies. The third is the maintenance question, and it is the honest centre of the project. Web Start is a technology the Java ecosystem has moved away from, and every future Java release is another version that has to be tested and supported by a small group, and the security fixes for Java 8 ended in 2019, so the underlying runtime that many of these applications still depend on is out of support by the vendor's own schedule. OpenWebStart makes the launcher available, and it cannot make the runtime supported. The fourth is the split repository, which for a user is irrelevant and for a contributor is a real tax, since a behaviour change has to be made upstream in IcedTea-Web and then picked up here, and the two projects are maintained by related but distinct groups. And the fifth is the trust question, because an installer that runs and updates itself on user machines is a distribution channel, and enterprise environments that restrict software installation will need the MSI and package variants that the documentation directory presumably covers rather than the generic installer.

## Conclusion

Adopt OpenWebStart if you run enterprise applications that are still launched through JNLP and need them to keep working on a supported Java version. Skip it if the applications in question have been migrated to a browser based launch, since that removes the problem rather than solving it. Verify first which Java versions your build targets, since the project's first goal is Java 8 LTS with Java 11 support described as coming later, and read the licence with its exceptions, since the installer's packaging carries obligations that the GPLv2 baseline alone does not describe.

## FAQ

### Why was OpenWebStart created?

Java Web Start was deprecated in Java 9 and removed from Oracle's JDK distributions starting with Java 11, so clients on a current Java could no longer run JWS-based applications. Public support for Java 8 also ended in the second quarter of 2019, so companies were left with neither a working launcher nor security fixes for the old runtime.

### What is the difference between OpenWebStart and IcedTea-Web?

All Web Start functionality is developed in the IcedTea-Web repository of the AdoptOpenJDK organisation, together with Red Hat and other members of that community. The OpenWebStart repository contains only the sources needed to create enterprise-ready, user-friendly native installers, built on the IcedTea-Web core, which keeps the packaging work separate from the feature work.

### Which Java versions does OpenWebStart target and what licence applies?

The first goal of the project is to target Java 8 LTS versions, with support for Java 11 LTS described as coming in the near future, and the approach is vendor independent so that it does not depend on a specific Java vendor or distribution. The project is released as open source under GPLv2 with exceptions, described in the LICENSE.md file at the root of the repository.

## Sources

- [Issues](https://github.com/karakun/OpenWebStart/issues)
- [karakun/OpenWebStart on GitHub](https://github.com/karakun/OpenWebStart)
- [Project website](https://openwebstart.com)
- [README](https://github.com/karakun/OpenWebStart/blob/master/README.md)
- [Releases](https://github.com/karakun/OpenWebStart/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/karakun-openwebstart