Bug#1061060: javaws fails to run Supermicro (Aten) iKVM remote consoles

[Rich Otero]

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:

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)

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)

I think the relevant change was implemented in OpenJDK 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

On Wed, 17 Jan 2024 09:15:26 +0100 Christian Schwamborn <
cs at mail.architektur.tu-darmstadt.de> wrote:
> Package: icedtea-netx
> Version: 1.8.8-2
>
> In some more recent update of icedtea-netx, I can't determine which
> exactly, the pack200 libs must have been removed from javaws.jar
> Keeping older java versions around to access such devices can't help if
> javaws is unable to fetch the jar files from those as they might be
> compressed.
>
> 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 kind of
> enterprise equipment still running somewhere.
>
> Let me ask a question: Who uses javaws nowadays?
> My wild guess: Mostly people having to access hardware equipment, where
> 'the industry' even today implements their user interface with java
> beside the fact that java is one of the worst ideas someone came up with.
> Sure, the more recent versions of Supermicro boards (Fujitsu as well)
> also provide a html5 implementations, but sadly they are in some areas
> not as 'finished' as they should be, so I still have to rely on their
> java counterparts.
> I don't want to create a debate about security. Everyone running that
> sort of stuff should know not to expose those interfaces anywhere and
> has to hack half his java security settings anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-java-maintainers/attachments/20240402/c3dec603/attachment.htm>