You are not logged in.
Hi everyone,
I'm wondering if in 2023 there's a way to run an old corporate java applet on wayland (weston).
Every idea is welcome and very much appreciated.
Thanks
Offline
Is wayland even relevant to this question? Is there even a way to run your applet under Xorg?
Historically these would mainly be opened in a web browser - and all major web browsers can run on Wayland. But they've also pretty much all ditched NPAPI as far as I know - and this is no less true when they are running under Xorg.
There's also java's own appletviewer which allegedly can run these directly. I don't have experience with this - but still whether or not it would work doesn't have anything to do with weather you are running under Xorg or Wayland (as java runs fine on Wayland too).
Aside, are you actually using weston?
Last edited by Trilby (2023-07-19 12:32:26)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Thanks for your reply.
wayland is relevant in this case because I don't have any x server available here, but if I had it installed I could also install an old firefox version + java 8 for having npapi "working". I use weston because it is almost perfect for my simple needs, then the simpler the better ![]()
The applet viewer could be a good solution but I don't know if it works on wayland.
Having a VM only for npapi is a nonsense ![]()
Offline
I could also install an old firefox version + java 8 for having npapi "working".
Why would that be any harder on wayland? It might be impossible - but no more so on wayland than Xorg. Firefox 84 was the last version to support NPAPI, and that was built against gtk3 and will (would have) run fine on wayland. So again, wayland is not relevant.
However, installing an ancient browser will be highly problematic. I'll not even go into the security risks (which should be considered), but what will stop you even faster is that firefox 84 is built against old libraries and will not run on a current arch linux system (neither Xorg nor Wayland). You could try to rebuild firefox yourself from old source code to get around this problem - I'm not sure how well that would work, but if it works at all, it will run just as well under Wayland as under Xorg.
The applet viewer could be a good solution but I don't know if it works on wayland.
Why don't you know? There's only one way to find out. The appletviewer itself will run just fine under Wayland - whether or not it can run your particular app is another question (but this still has nothing to do with Wayland).
Last edited by Trilby (2023-07-21 12:20:00)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Are you sure about FF 84 ? Sounds good.
Last time I used it with NPAPI was with something around 50. About the libraries I already did what you suggested for another FF esr version time ago, unfortunately it doesn't support npapi.
This applet requires java 8, I didn't do any test with the viewer because that java version is an old one. Well, I'll do this for sure (hopefully in August). Thanks again for your tips
Offline
Are you sure about FF 84 ?
No, I just found this which apparently has a grossly misleading title. Firefox 84 was the last version with any remnants of NPAPI, but at that time it was (apparently) only for flash and other NPAPI components were removed with version 52 which would have initially build against gtk 3.22 or 3.24 (it's too far back to even be in the ALA now though) - but in any case, gtk was supporting wayland for 5 years by that point.
So building an ancient firefox will be difficult - but if you do, it will run on wayland.
Last edited by Trilby (2023-07-21 12:20:32)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
This applet requires java 8, I didn't do any test with the viewer because that java version is an old one.
Java 8 is old but still alive and well, supported by Openjdk and in archlinux repos.
See https://wiki.archlinux.org/title/Java for info (including how to switch between different java versions on archlinux) .
Incase you're worried about maintenance of java 8, https://wiki.openjdk.org/display/jdk8u/Main shows there were 5 java 8 updates in 2022 and 2 this year.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Quick update:
FF 84 up and running on wayland, jre 8.241 installed.
But I'm doing something wrong because FF doesn't see any java plugin. Any idea?
Thanks
Offline
What plugin are you using / trying to use? Have you built a version-matched icetea-web or similar plugin?
Have you tried the appletviewer yet?
Last edited by Trilby (2023-07-25 14:11:51)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I installed both FF 84 (beta7) and 71.
I tried both openjdk 8 232 (+icedtea-web) and jre8 241 (without icedtea, linking libnpjp2.so). Nothing seems to work unfortunately.
However installing icedtea pacman shows "pending" for the web plugin, i don't know why.
Thanks for your reply back
Offline
I found this from Oracle:
Many browser vendors have removed NPAPI based plugin support. Therefore, the Java Plugin will not register with any modern browsers, such as Firefox ( Firefox 52+) and Chrome (Chrome 42+).
Manually linking the Java plugin libraries to the Mozilla plugins directory may cause the Firefox browser to crash on Linux during startup, due to incompatibilities with 'glibc' versions in JDK 8u191 and later releases. The crash might also occur if the link was manually created for an earlier JRE and a user updates to JDK 8u191 or later releases. For more information, see the Known Issues section of the JDK 8u191 release notes.
So FF 71 and 84 seem to be not good for the purpose, but 51 works on gtk2 if i remember well, i fear the same for chrome 41.
It's a dead end so far ![]()
Offline
I believe I have a possible walkaround, I keep you updated!
Offline
quick update: I installed waterfox-current + jre8.241 (in waterfox I had to set security.sandbox.content.level;0)
java plugin is now recognized and called by the browser, but the problem is that every call goes to a dead end : java plugin cannot open display (gtk2-> x11).
I removed gtk2 to get better certainty, and i got:
error while loading shared libraries: li bgtk-x11-2.0.so.0
so again a dead end unfortunately ![]()
Offline
Have you tried the appletviewer yet?
As far as I can see you haven't answered that.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I don't have direct access to the applet, I only got a web link (a subdomain) which doesn't work with the applet viewer unfortunately
Offline
You just need to give the full url. If the domain name by itself would work in a web browser, then the url is most likely $domain/index.html. However, you could also check with something like `curl -LI $domain` or `curl -LI $domain/index.html` to see if there are any redirects.
While I previously said that the relevant versions of gtk3 would work fine on wayland, gtk2 certainly will not as you have seen.
Can you share the link to this applet?
Last edited by Trilby (2023-07-26 13:11:08)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Java doesn't support Wayland natively either. You'll need xwayland to run appletviewer, so if gtk2 is not an option because it uses X11, appletviewer wouldn't fix that.
Offline
It's been a while since I've used java - but can't it be set to just use one of the major toolkits on the system (e.g., gtk or qt) for the UI?
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
No, that's not how the GUI toolkits in the Java standard library work. AWT requires X11, and Swing builds on AWT for rendering primitives and window server integration.
PS: Perhaps you're referring to the look and feel thing in Swing? By means of the Gtk3 L&F Swing can use Gtk3 to draw widgets (e.g. buttons, etc.) but it still uses AWT (and hence X11) for the actual window system integration.
In other words, Java can draw with Gtk3, but only onto X11 windows, because there's no support for Wayland surfaces in AWT.
Last edited by 3beb6e7c46a615a (2023-07-26 15:18:18)
Offline
I feared it. I don't see a reasonable way for having it working here unfortunately. But I can't throw in the towel now. I sleep on it and keep you posted in case something good happens, thanks guys for your help.
Offline
A possible solution could be the simplest x11 setup ever, just for starting the browser when needed, nothing else. Suggestions for this simple setup?
Offline
xwayland? Most compositors start it on demand as far as I know.
Offline
I'd prefer the bare minimum for x11. Browser and plugin should be ok now. Thanks
Offline
for testing purpose I enabled xwayland and i got this error from jre:
pipe error (124): Connection reset by peer: file /home/ubuntu/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line
358
So I switched to another java version (8.261), same error.
Then i removed jre and installed jre8-openjdk +icedtea, but I got another error:
OpenJDK Runtime Environment (build 1.8.0_265-b01)
OpenJDK 64-Bit Server VM (build 25.265-b01, mixed mode)
Unable to use Firefox's proxy settings. Using "DIRECT" as proxy type.
I tried to set direct connection from the browser, but nothing changed.
With jre control panel I can set the binary of waterfox, with icedtea I don't see that option.
Having this java plugin working is becoming an epic poem -.-
Offline
quick update: java plugin (jre8) seems to be correctly activated but I only see a blank frame and the same happens on x11, so it's not related on wayland now. I'm puzzled.
current setup x11 + jre8.261 + waterfox-current.
Btw, before getting that blank frame I got the pop up message from java asking me to update it and I chosen "Later", so the plugin seems to be available to the browser but it doesn't work here:
https://www.math.uh.edu/mathonline/Java … stPage.htm
Offline