[Software][Solved] Old Java Web Start Application Fails to Initialize with IcedTea and OpenJDK 8

[rotero]

I manage a lot of old servers that have Supermicro motherboards. They provide a remote console (Aten iKVM) in the form of a Java Web Start application (JNLP file), which requires a particularly old version of the JRE. Until recently, I was successfully using IcedTea on Debian 10 to run the KVM console. I had to replace that laptop due to a hardware problem, so I'm now trying to make the KVM console function properly on Debian 12.5. It's practically the same task as described in this post from @cogitech a few months ago. Unfortunately, I haven't been able to get it to work yet. I think I know what the problem is, but I don't have enough experience troubleshooting Java applications to be certain.

I have installed icedtea-netx and nvidia-openjdk-8-jre:

Code: Select all

$ apt-cache policy icedtea-netx nvidia-openjdk-8-jre 
icedtea-netx:
  Installed: 1.8.8-2
  Candidate: 1.8.8-2
  Version table:
 *** 1.8.8-2 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages
        100 /var/lib/dpkg/status
nvidia-openjdk-8-jre:
  Installed: 9.+8u372-ga-1~11.8.0-5~deb12u1
  Candidate: 9.+8u372-ga-1~11.8.0-5~deb12u1
  Version table:
 *** 9.+8u372-ga-1~11.8.0-5~deb12u1 500
        500 http://deb.debian.org/debian bookworm/non-free amd64 Packages
        100 /var/lib/dpkg/status

I used itweb-settings to set deployment.jre.dir in ~/.config/icedtea-web/deployment.properties to the OpenJDK 8 directory (/usr/lib/jvm/java-8-openjdk-amd64/jre). With this configuration, javaws can run the JNLP and it downloads the two required JARs into its cache, iKVM__V1.69.27.0x0.jar.pack.gz and liblinux_x86_64__V1.0.8.jar.pack.gz. But the application fails to initialize. If I look at the Java console or run JNLP in a terminal (javaws -verbose launch.jnlp), I think I see the cause of the problem:

Code: Select all

Downloading file: https://brody-ipmi:443/liblinux_x86_64__V1.0.8.jar.pack.gz into: /home/rotero/.cache/icedtea-web/cache/4/https/brody-ipmi/443/liblinux_x86_64__V1.0.8.jar.pack.gz

<snip>

Downloading file: https://brody-ipmi:443/iKVM__V1.69.27.0x0.jar.pack.gz into: /home/rotero/.cache/icedtea-web/cache/5/https/brody-ipmi/443/iKVM__V1.69.27.0x0.jar.pack.gz

<snip>

java.lang.UnsupportedOperationException: Pack200 compression is no longer supported, cannot unpack https://brody-ipmi:443/liblinux_x86_64__V1.0.8.jar.pack.gz
        at net.sourceforge.jnlp.cache.ResourceDownloader.uncompressPackGz(ResourceDownloader.java:502)
        at net.sourceforge.jnlp.cache.ResourceDownloader.downloadPackGzFile(ResourceDownloader.java:400)
        at net.sourceforge.jnlp.cache.ResourceDownloader.downloadResource(ResourceDownloader.java:364)
        at net.sourceforge.jnlp.cache.ResourceDownloader.run(ResourceDownloader.java:117)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:750)

Disconnecting sun.net.www.protocol.https.DelegateHttpsURLConnection:https://brody-ipmi:443/liblinux_x86_64__V1.0.8.jar.pack.gz
Removed sun.net.www.protocol.https.DelegateHttpsURLConnection:https://brody-ipmi:443/liblinux_x86_64__V1.0.8.jar.pack.gz
java.lang.UnsupportedOperationException: Pack200 compression is no longer supported, cannot unpack https://brody-ipmi:443/iKVM__V1.69.27.0x0.jar.pack.gz
        at net.sourceforge.jnlp.cache.ResourceDownloader.uncompressPackGz(ResourceDownloader.java:502)
        at net.sourceforge.jnlp.cache.ResourceDownloader.downloadPackGzFile(ResourceDownloader.java:400)
        at net.sourceforge.jnlp.cache.ResourceDownloader.downloadResource(ResourceDownloader.java:364)
        at net.sourceforge.jnlp.cache.ResourceDownloader.run(ResourceDownloader.java:117)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:750)

Disconnecting sun.net.www.protocol.https.DelegateHttpsURLConnection:https://brody-ipmi:443/iKVM__V1.69.27.0x0.jar.pack.gz
Removed sun.net.www.protocol.https.DelegateHttpsURLConnection:https://brody-ipmi:443/iKVM__V1.69.27.0x0.jar.pack.gz
JAR https://brody-ipmi:443/iKVM__V1.69.27.0x0.jar not found. Continuing.

<snip>

JAR https://brody-ipmi:443/liblinux_x86_64__V1.0.8.jar not found. Continuing.

<snip>

netx: Initialization Error: Could not initialize application. (Fatal: Initialization Error: Unknown Main-Class. Could not determine the main class for this application.)
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line.
        at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:823)
        at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:531)
        at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:946)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Unknown Main-Class. Could not determine the main class for this application.
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:775)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:337)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:420)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:494)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:467)
        at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:815)
        ... 2 more

It seems to me that javaws can't decompress the application's JARs because "Pack200 compression is no longer supported." I found Debian bug report #1061060, which implies that Pack200 support was removed from the javaws program provided by icedtea-netx:

In some more recent update of icedtea-netx, I can't determine which, exactly, the pack200 libs must have been removed from javaws.jar.

Even recent system boards from Supermicro ship their JAR libs as .jar.pack.gz files. I know, it's deprecated for ages, but tell it to them. Even if they change it now, they won't update older firmwares and there are plenty around, not only on server boards, but all kinds of enterprise equipment still running somewhere.

Have I diagnosed this correctly? Is there anything I can do about it? I could probably get an old version of icedtea-netx from a previous Debian release, but I strongly prefer not to make a "Frankendebian…"

[Aki]

Hello,

I manage a lot of old servers that have Supermicro motherboards. They provide a remote console (Aten iKVM) in the form of a Java Web Start application (JNLP file), which requires a particularly old version of the JRE
[..]
I was successfully using IcedTea on Debian 10 to run the KVM console

What is the "particularly old version of the JRE" that is required by the Supermicro motherboards (according to Supermicro specifications) to run the java remote consoles ?

If I understand correctly, Debian Buster uses Java 7.2:

• https://sources.debian.org/src/icedtea-web/1.7.2-2/

[rotero]

What is the "particularly old version of the JRE" that is required by the Supermicro motherboards (according to Supermicro specifications) to run the java remote consoles ?

If I understand correctly, Debian Buster uses Java 7.2:

• https://sources.debian.org/src/icedtea-web/1.7.2-2/

Yes, in Debian 10, I think I was using icedtea-web 1.7.2 (possibly already renamed to icedtea-netx) and openjdk-8-jre 8u222. In Debian 12, we now have icedtea-netx 1.8.8 and nvidia-openjdk-8-jre 8u372. If my understanding is correct, it's the OpenJDK software that causes this problem. I think the relevant change was implemented in December 2019:

https://hg.openjdk.org/jdk/jdk/rev/f236fd5d0c2c
https://bugs.openjdk.org/browse/JDK-8234542
https://bugs.openjdk.org/browse/JDK-8234596

[Aki]

Hello,

You can try installing locally (decompressing from a tar.gz in a subdirectory of your standard user, i.e. not root) an older java version (i.e. 7) with Pack200 still available.

You may download it from:

• https://www.oracle.com/java/technologies/javase/javase7-archive-downloads.html

[Aki]

@rotero: did you sort it out ?

[rotero]

@rotero: did you sort it out ?

I may have just found a solution today. Previously, I was using OpenJDK 8u222, so I looked through the section of the Oracle archive for Java SE 8 (8u211 and later). I tried a few of the most recent versions of the Java SE Runtime Environment for Linux x64, specifically 8u401 and 8u391. Both of those fail to run the application due to a security error:

Code: Select all

JNLPException[category: Security Error : Exception: null : LaunchDesc: 
<jnlp spec="1.0+" codebase="https://ssd5-ipmi:443/">
  <information>
    <title>ATEN Java iKVM Viewer</title>
    <vendor>ATEN</vendor>
    <description>Java Web Start Application</description>
  </information>
  <security>
    <all-permissions/>
  </security>
  <resources>
    <property name="jnlp.packEnabled" value="true"/>
    <j2se version="1.6.0+" initial-heap-size="128M" max-heap-size="128M" java-vm-args="-XX:PermSize=32M -XX:MaxPermSize=32M"/>
    <jar href="iKVM__V1.69.39.0x0.jar" download="eager" main="true"/>
  </resources>
  <resources os="Windows" arch="x86">
    <nativelib href="libwin_x86__V1.0.12.jar" download="eager"/>
  </resources>
  <resources os="Windows" arch="x86_64">
    <nativelib href="libwin_x86_64__V1.0.12.jar" download="eager"/>
  </resources>
  <resources os="Windows" arch="amd64">
    <nativelib href="libwin_x86_64__V1.0.12.jar" download="eager"/>
  </resources>
  <resources os="Linux" arch="i386">
    <nativelib href="liblinux_x86__V1.0.12.jar" download="eager"/>
  </resources>
  <resources os="Linux" arch="x86">
    <nativelib href="liblinux_x86__V1.0.12.jar" download="eager"/>
  </resources>
  <resources os="Linux" arch="x86_64">
    <nativelib href="liblinux_x86_64__V1.0.12.jar" download="eager"/>
  </resources>
  <resources os="Linux" arch="amd64">
    <nativelib href="liblinux_x86_64__V1.0.12.jar" download="eager"/>
  </resources>
  <resources os="Mac OS X" arch="x86_64">
    <nativelib href="libmac_x86_64__V1.0.12.jar" download="eager"/>
  </resources>
  <application-desc main-class="tw.com.aten.ikvm.KVMMain">
    <argument>https://ssd5-ipmi:443/</argument>
    <argument>iKVM__V1.69.39.0x0.jar</argument>
    <argument>libwin_x86__V1.0.12.jar</argument>
    <argument>libwin_x86_64__V1.0.12.jar</argument>
    <argument>libwin_x86_64__V1.0.12.jar</argument>
    <argument>liblinux_x86__V1.0.12.jar</argument>
    <argument>liblinux_x86__V1.0.12.jar</argument>
    <argument>liblinux_x86_64__V1.0.12.jar</argument>
    <argument>liblinux_x86_64__V1.0.12.jar</argument>
    <argument>libmac_x86_64__V1.0.12.jar</argument>
    <argument>ssd5-ipmi</argument>
    <argument>B7Jdry7r7VrVvCH</argument>
    <argument>XTJo/ew==</argument>
    <argument>ssd5-ipmi</argument>
    <argument>63630</argument>
    <argument>63631</argument>
    <argument>0</argument>
    <argument>0</argument>
    <argument>1</argument>
    <argument>5900</argument>
    <argument>623</argument>
    <argument>1</argument>
  </application-desc>
</jnlp> ]
	at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
	at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
	at com.sun.javaws.Launcher.prepareResources(Unknown Source)
	at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
	at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
	at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
	at com.sun.javaws.Launcher.launch(Unknown Source)
	at com.sun.javaws.Main.launchApp(Unknown Source)
	at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
	at com.sun.javaws.Main.access$000(Unknown Source)
	at com.sun.javaws.Main$1.run(Unknown Source)
	at java.lang.Thread.run(Thread.java:750)

I tried disabling various security settings that seemed relevant using bin/ControlPanel (jcontrol) from the tarball, but that had no effect.

There was no 8u222 tarball in the archive, so I tried going back even further to 7u80. That seems to fail due to an SSL handshake failure.

Code: Select all

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
	at sun.security.ssl.Alerts.getSSLException(Unknown Source)
	at sun.security.ssl.Alerts.getSSLException(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.recvAlert(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
	at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)
	at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)
	at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
	at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
	at com.sun.deploy.net.BasicHttpRequest.doGetRequest(Unknown Source)
	at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
	at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
	at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
	at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
	at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

Maybe that could be made to work by setting options to allow old SSL or TLS protocol versions or to allow executing unsigned code, but I didn't try.

I looked again through the section for 8u211 and later and found the version that is nearest to what I was previously using, 8u221. For reasons that I don't understand, the javaws binary in this tarball can run the Supermicro JNLP and the basic functions of the virtual KVM seem to work as expected.

[Aki]

Hello,

Thanks for reporting back.

[..]
I looked again through the section for 8u211 and later and found the version that is nearest to what I was previously using, 8u221. For reasons that I don't understand, the javaws binary in this tarball can run the Supermicro JNLP and the basic functions of the virtual KVM seem to work as expected.

I'm glad you sorted it out. :)

Please, mark the discussion as "solved" manually adding the text tag "[Solved]" at the beginning of the subject of the first message (after other tags, if any); i.e. :

[Software][Solved] Old Java Web Start Application Fails to Initialize with IcedTea and OpenJDK 8

Happy Debian !