<div dir="ltr"><div>I also encountered this problem after switching from Debian 10.9 to Debian 12.5. The Aten remote KVM provided by Supermicro motherboards relies on JARs compressed by Pack200, so the application no longer works with icedtea-netx and nvidia-openjdk-8-jre:</div><div><br></div><div><font face="monospace">java.lang.UnsupportedOperationException: Pack200 compression is no longer supported, cannot unpack <a href="https://brody-ipmi:443/liblinux_x86_64__V1.0.8.jar.pack.gz">https://brody-ipmi:443/liblinux_x86_64__V1.0.8.jar.pack.gz</a><br>        at net.sourceforge.jnlp.cache.ResourceDownloader.uncompressPackGz(ResourceDownloader.java:502)<br>        at net.sourceforge.jnlp.cache.ResourceDownloader.downloadPackGzFile(ResourceDownloader.java:400)<br>        at net.sourceforge.jnlp.cache.ResourceDownloader.downloadResource(ResourceDownloader.java:364)<br>        at net.sourceforge.jnlp.cache.ResourceDownloader.run(ResourceDownloader.java:117)<br>        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)<br>        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)<br>        at java.lang.Thread.run(Thread.java:750)<br></font></div><div><font face="monospace"><br></font></div><div><font face="monospace">java.lang.UnsupportedOperationException: Pack200 compression is no longer supported, cannot unpack <a href="https://brody-ipmi:443/iKVM__V1.69.27.0x0.jar.pack.gz">https://brody-ipmi:443/iKVM__V1.69.27.0x0.jar.pack.gz</a><br>        at net.sourceforge.jnlp.cache.ResourceDownloader.uncompressPackGz(ResourceDownloader.java:502)<br>        at net.sourceforge.jnlp.cache.ResourceDownloader.downloadPackGzFile(ResourceDownloader.java:400)<br>        at net.sourceforge.jnlp.cache.ResourceDownloader.downloadResource(ResourceDownloader.java:364)<br>        at net.sourceforge.jnlp.cache.ResourceDownloader.run(ResourceDownloader.java:117)<br>        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)<br>        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)<br>        at java.lang.Thread.run(Thread.java:750)</font><br></div><div><br></div><div>I think the relevant change was implemented in OpenJDK in December 2019:</div><div><br></div><div><a href="https://hg.openjdk.org/jdk/jdk/rev/f236fd5d0c2c">https://hg.openjdk.org/jdk/jdk/rev/f236fd5d0c2c</a></div><div><a href="https://bugs.openjdk.org/browse/JDK-8234542">https://bugs.openjdk.org/browse/JDK-8234542</a><br></div><div><a href="https://bugs.openjdk.org/browse/JDK-8234596">https://bugs.openjdk.org/browse/JDK-8234596</a><br></div><div> </div>On Wed, 17 Jan 2024 09:15:26 +0100 Christian Schwamborn <<a href="mailto:cs@mail.architektur.tu-darmstadt.de">cs@mail.architektur.tu-darmstadt.de</a>> wrote:<br>> Package: icedtea-netx<br>> Version: 1.8.8-2<br>> <br>> In some more recent update of icedtea-netx, I can't determine which<br>> exactly, the pack200 libs must have been removed from javaws.jar<br>> Keeping older java versions around to access such devices can't help if<br>> javaws is unable to fetch the jar files from those as they might be<br>> compressed.<br>> <br>> Even recent system boards from Supermicro ship their jar libs as<br>> *.jar.pack.gz files. I know, it's deprecated for ages, but tell it to<br>> them. Even if they change it now, they won't update older firmwares and<br>> there are plenty around. Not only on server boards but all kind of<br>> enterprise equipment still running somewhere.<br>> <br>> Let me ask a question: Who uses javaws nowadays?<br>> My wild guess: Mostly people having to access hardware equipment, where<br>> 'the industry' even today implements their user interface with java<br>> beside the fact that java is one of the worst ideas someone came up with.<br>> Sure, the more recent versions of Supermicro boards (Fujitsu as well)<br>> also provide a html5 implementations, but sadly they are in some areas<br>> not as 'finished' as they should be, so I still have to rely on their<br>> java counterparts.<br>> I don't want to create a debate about security. Everyone running that<br>> sort of stuff should know not to expose those interfaces anywhere and<br>> has to hack half his java security settings anyway.<br></div>