JNLP File Documentation

Summary

A .jnlp file is a Java Network Launch Protocol descriptor: a small XML document that told Java Web Start which application JAR files to download from a server and run. Its MIME type is application/x-java-jnlp-file. The technology is discontinued — Oracle deprecated Java Web Start in Java 9 (2017) and removed it in Java 11 (September 2018) — so on a current Java a JNLP file does nothing until the open-source OpenWebStart is installed.

Technical details

FeatureValue
Full nameJava Network Launch Protocol file
File extension.jnlp
MIME typeapplication/x-java-jnlp-file
Format typeXML application-launch descriptor (plain text)
EncodingUTF-8 / UTF-16 XML 1.0
Root element<jnlp>
DeveloperSun Microsystems (later Oracle)
SpecificationJSR-56 (Java Network Launching Protocol and API)
Introduced2001 (Java Web Start, J2SE 1.3.1/1.4)
StatusDiscontinued — removed from Oracle Java 11 (Sept 2018)
Open standardPartial (JSR-56 public; no independent standards body)
Launcher (historical)javaws (Java Web Start)
Launcher (current)OpenWebStart / IcedTea-Web reimplementation
Delivery modelServer-hosted; re-downloaded on each launch
ReferencesJAR archives listed by <jar href>
Related extensions.jar, .java, .jsp
Specification URLjcp.org/en/jsr/detail?id=56
Structure at a glance

A JNLP file is plain-text XML with no binary signature. It begins with an <?xml version="1.0"?> declaration and a single root <jnlp> element whose spec, codebase and href attributes give the protocol version and the base URL of the application server. Inside sit <information> (title, vendor), <security> (requested permissions), <resources> (the required Java version and the <jar href="..."> list), and <application-desc main-class="..."> naming the entry point. The file holds no code — only pointers to the JARs. Open it in any text editor to read the codebase before trusting it.

What is a JNLP file?

JNLP stands for Java Network Launch Protocol, an XML descriptor format Sun Microsystems introduced in 2001 and standardised as JSR-56. A .jnlp file is the small text document behind a “Launch” button on a web page: clicking the link downloaded the descriptor, and the javaws (Java Web Start) launcher read it, fetched the JAR files it named from a server, cached them, verified their signatures, and ran the application on the desktop outside the browser. Its MIME type is application/x-java-jnlp-file.

The file itself contains no program code. It is a manifest of URLs and settings, typically 1–4 KB, that you can read in any text editor. JNLP was the standard delivery method for enterprise tools, server remote consoles (Dell iDRAC, HP iLO, Lenovo IMM), lab instruments and government portals. The technology is now discontinued: Oracle deprecated Java Web Start in Java 9 (September 2017) and removed it, along with the browser plugin, in Java 11 (September 2018). No current Oracle or OpenJDK build ships javaws, which is why double-clicking a JNLP on a modern system does nothing.

The jnlp root element: spec, codebase and href

After the XML declaration comes a single <jnlp> root element whose attributes anchor everything else. spec is the JNLP version the file requires (commonly 1.0+ or 6.0+). codebase is the base URL against which every relative resource path is resolved, and href is the location of the JNLP file itself, which lets the launcher re-download an updated copy on the next run.

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="6.0+"
      codebase="https://apps.example.com/console"
      href="viewer.jnlp">
  ...
</jnlp>

Because codebase names the server the application code is pulled from, it is the single most important field for judging whether a JNLP is safe: a launcher will download and execute whatever JARs live under that URL. Reading it in a text editor before opening the file is the practical security check.

The resources element: JVM version and JAR list

The <resources> element is the heart of the descriptor. It states which Java runtime the application needs and lists every JAR to download, plus any system properties or native libraries.

<resources>
  <j2se version="1.8+" href="http://java.sun.com/products/autodl/j2se"/>
  <jar href="lib/console.jar" main="true"/>
  <jar href="lib/support.jar"/>
  <property name="log.level" value="INFO"/>
</resources>

The <j2se> (or <java>) element pins the required JVM version, e.g. 1.8+. Each <jar> element gives a path relative to codebase; exactly one is marked main="true", the archive whose manifest names the class to run. Resources can be wrapped in <resources os="Windows"> blocks so the launcher selects platform-specific JARs or native libraries. This list is also the manual workaround for a dead server console: combine codebase with each <jar href>, download the JARs directly, and run the signed main JAR with java -jar.

application-desc: entry point and arguments

The final element names what to launch. <application-desc> is used for a standalone Java application; its main-class attribute is the fully-qualified class whose main(String[]) method starts the program, and nested <argument> elements pass command-line arguments.

<application-desc main-class="com.example.console.Main">
  <argument>--host=10.0.0.5</argument>
  <argument>--port=443</argument>
</application-desc>

An alternative <applet-desc> element existed for launching browser applets outside the browser, and <component-desc> marked a JNLP that only supplied shared libraries to other JNLP files rather than launching anything. When the launcher finished parsing, it had a complete picture: which JVM, which JARs, what permissions and which class to invoke, all from this one text file.

Why JNLP does nothing today, and what replaced javaws

Java Web Start was part of Oracle’s client deployment stack, removed wholesale when Oracle dropped applets and Web Start after Java 8. Because the format is inert XML, the file survives intact; what disappeared is the javaws program that knew how to act on it. Two paths remain for legacy applications. OpenWebStart, an open-source reimplementation by Karakun based on IcedTea-Web, registers itself as the .jnlp handler, downloads a matching JVM and runs the descriptor on current systems; it is the maintained recommendation. A legacy Oracle Java 8 runtime still contains javaws but means running an out-of-support Java. Many vendors have since replaced JNLP consoles with HTML5 equivalents, so checking a server’s firmware for an HTML5 option is often the cleanest fix. IcedTea-Web itself is no longer actively developed; OpenWebStart is its successor.

How JNLP relates to the JAR files it launches

A JNLP file and a JAR are different things that people routinely confuse. The JAR is the actual application: a ZIP archive of compiled .class files with a manifest, the thing that runs. The JNLP is only a launcher that says which JARs to fetch and which class inside them to start. Deleting a JNLP from a Downloads folder removes nothing from the application, because the website re-issues a fresh descriptor every time the launch link is clicked; the JARs are cached separately by the launcher. This separation is the whole point of Web Start: the descriptor is versioned on the server, so each launch could pull updated JARs automatically without the user reinstalling anything.

Why an unexpected JNLP attachment is treated as an installer

The JNLP file cannot execute anything by itself — it is XML — but what it instructs Java to do is download and run a full desktop application, historically with <all-permissions/>. That is exactly the behaviour of an installer, and it is why JNLP e-mail attachments were used to deliver malware before Web Start was removed. On any machine that still has OpenWebStart or legacy Java 8, the safe rule is to open a JNLP only from a server you trust, read the codebase and <jar href> URLs in a text editor first, and delete unexpected .jnlp attachments unread. On a modern Java with no launcher installed, the file is harmless because nothing can act on it.

References