You are not logged in.
Hi, all.
Today, as part of a regular pacman -Syu, I updated jre-openjdk:
jre-openjdk 25.0.2.u10-1 --> 26.u35-1
After that, the appliaction «yED Graph Editor» (1:3.25.1-1) stopped working. I got the following error message in a dialog box:
yED has encountered the following error: NoClassDefFoundError: java/applet/Applet
Please check if a more recent version of yED or java is available since this problem may already be resolved in the latest version.
Otherwise, please consider reporting this error and have a look at the yED forum and the yED manual which may contain more information.
I also got this error report:
java.lang.NoClassDefFoundError: java/applet/Applet
at com.jidesoft.action.DefaultDockableBarDockableHolder.createDockableBarManager(Unknown Source)
at com.jidesoft.action.DefaultDockableBarDockableHolder.initFrame(Unknown Source)
at com.jidesoft.docking.DefaultDockableHolder.<init>(Unknown Source)
at com.jidesoft.action.DefaultDockableBarDockableHolder.<init>(Unknown Source)
at com.yworks.A.V.E.<init>(Unknown Source)
at com.yworks.A.V.D.ā(Unknown Source)
at com.yworks.A.K.S.ā(Unknown Source)
at com.yworks.A.V.run(Unknown Source)
at com.yworks.A.X$1.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: java.applet.Applet
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
... 10 moreThere does not seem to have been released any newer version of yED Graph Editor that I can find. As a temporary workaround, I downgraded jre-openjdk like this:
$ sudo pacman -U /var/cache/pacman/pkg/jre-openjdk-25.0.2.u10-1-x86_64.pkg.tar.zstThis makes me able to run yED Graph Editor again, for now.
My question:
Is there any solution to make yED Graph Editor working again, without me being stuck with an old version of jre-openjdk?
Edit: Typo in pacman command.
Last edited by SeagullFish (2026-03-21 14:42:17)
Offline
Mod note: moving to AUR Issues.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
Offline
Q1: Wouldn't it be better to try this instead?
https://archlinux.org/packages/extra/x8 … 5-openjdk/
I thought that the Arch Linux developers officially were encouraging people to install software from official repos rather than from the AUR.
Q2: If I install jre25-openjdk, then I assume that I am stuck with jre25, while the rest of the world is moving on to jre26. Or can I have both versions installed at the same time?
Q3: If yes to Q2: How can I tell yED to run from jre25, while all other software is running from jre26?
Offline
Oh, wasn't aware that vanilla jdk25 is also kept in the repos.
Offline
Awesome! Section 2.5 on that ArchWiki page provided the exact help that I needed. Thank you. Case [SOLVED].
Offline
Oh, wasn't aware that vanilla jdk25 is also kept in the repos.
from https://openjdk.org/projects/jdk/25/
JDK 25 will be a long-term support (LTS) release from most vendors
It should be available for many years.
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
Additional notes:
Here is a summary of what I did that worked. I believe this procedure will leave the least mess behind.
1. Made sure that jre-openjdk was updated to jre26:
$ sudo pacman -Syu2. Installed jre25-openjdk:
$ sudo pacman -S jre25-openjdk3. Made sure that both jre25 and jre26 were detected, and that jre26 was set to default:
$ archlinux-java status
Available Java environments:
java-25-openjdk
java-26-openjdk (default)4. Edited /usr/bin/yed with admin privileges:
#!/bin/sh
# COMMENTED OUT THIS LINE:
# /usr/bin/java -jar /usr/share/java/yed/yed.jar "$@"
# ADDED THESE LINES:
export PATH="/usr/lib/jvm/java-25-openjdk/bin/:$PATH"
/usr/lib/jvm/java-25-openjdk/bin/java -jar /usr/share/java/yed/yed.jar "$@"Offline
export PATH="/usr/lib/jvm/java-25-openjdk/bin/:$PATH"
/usr/lib/jvm/java-25-openjdk/bin/java -jar /usr/share/java/yed/yed.jar "$@"When you set path you can use java instead of usr/lib/jvm/java-25-openjdk/bin/java .
Also it's a good idea to use exec java to ensure control is passed back to the launcher script and it's closed cleanly .
see https://gitlab.archlinux.org/archlinux/ … freecol.sh for an example.
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
this is ALL wrong!
the only right solution is to report up to the devs the keep using something what died 15 years ago and that they should remove it from thier code
the problem here is that this graph editor for whatever reason still uses Applets - something what died over a decade ago - and has no point in a desktop application anyway - so for whatever they abuse it - it shows the catastrophic quality of that product
Offline
What on earth are you talking about ?
java 11 was released in 2018 and had an update 2 months ago.
The other java versions mentioned in this thread are java 25 and java 26 .
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
you missed the point
the error refers to plain old java awt applets - https://en.wikipedia.org/wiki/Java_applet
anything awt was superseeded by swing with at least 1.4 - so the fact that for whatever reason they refer to the base class instead of to at least the swig version javax.applet.JApplet raises several red flags
aside from that: (J)Applet is a top-level window and the main interface be loaded by a browser (or the applet-viewer) - other than that these two top-level containers have no point and don't work anyway - thier methods gets called from outside from the browser (which JavaScript oroginal got its name from: to interact with java applets through the applet api)
yED is a standalone desktop application - it should have no reference to (J)Applet at all whatsoever - unless back 15+ years ago it also had a browser-based variant - whoch then raises the question why such code got into the mainline anyway
overall the fact that yED has any reference to Applet in 2026 is just horrible
Offline
they should remove it from thier code
They probably "should" not be using java itfp…
Offline
When you set path you can use java instead of usr/lib/jvm/java-25-openjdk/bin/java .
Also it's a good idea to use exec java to ensure control is passed back to the launcher script and it's closed cleanly .
I guess you mean like this (just to clarify if anyone else should run into a similar issue in the future):
export PATH="/usr/lib/jvm/java-25-openjdk/bin/:$PATH"
exec java -jar /usr/share/java/yed/yed.jar "$@"Offline
this is ALL wrong!
the only right solution is to report up to the devs the keep using something what died 15 years ago and that they should remove it from thier codethe problem here is that this graph editor for whatever reason still uses Applets - something what died over a decade ago - and has no point in a desktop application anyway - so for whatever they abuse it - it shows the catastrophic quality of that product
yED is a standalone desktop application - it should have no reference to (J)Applet at all whatsoever - unless back 15+ years ago it also had a browser-based variant - whoch then raises the question why such code got into the mainline anyway
Actually, I do agree that yED could have benefited from certain improvements and updates. In my opinion, the user interface is somewhat reminiscent of how such an application would have looked around 2000-2010. It appears a bit outdated, and is not the prettiest thing I've seen. The ease of use is also a bit limited. Adjusting and moving objects around feels a bit cumbersome, as the objects will not always snap into place at the exact coordinates that I want. Also, the application does not visualize where I am about to move an object from, while I am moving it. I think that yWorks could benefit from learning a bit about how, for example, the user interface of Autodesk AutoCAD works.
Unfortunately, I have neither expertise nor experience in developing software with a graphical user interface. I am not qualified to say what it would take to change the source code to fit modern libraries and plattforms. Despite me thinking that the development of this software should have been more progressful during the last several years, I don't feel confident that I am the proper person to give such a harsh feedback to yWorks. Also, since they are offering this software free of charge, I probably don't have quite the same basis for complainting as I would have had if this was software that I had paid for.
They probably "should" not be using java itfp…
I don't understand why yWorks have built yED on java either. Ultimately, it is their choice to do so, choosing whatever platform they see fit. However, I don't understand their intentions, or what advantages they attempt to achieve by this.
Offline
They bought into the portability … err… "promise" - but I mostly wanted to slap cryptearth w/ the shouldland video ![]()
Offline
Lone_Wolf wrote:When you set path you can use java instead of usr/lib/jvm/java-25-openjdk/bin/java .
Also it's a good idea to use exec java to ensure control is passed back to the launcher script and it's closed cleanly .I guess you mean like this (just to clarify if anyone else should run into a similar issue in the future):
export PATH="/usr/lib/jvm/java-25-openjdk/bin/:$PATH" exec java -jar /usr/share/java/yed/yed.jar "$@"
Yes, that's exactly what I meant.
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
Update:
A new version of yed[AUR] (1:3.25.1-2) was released 2026-04-07. This new version is dependent on archlinux-java-run[AUR] and jre25-openjdk. I assume that these dependencies were added as part of an attempt of a workaround to the very issue of this thread.
The developer website of archlinux-java-run[AUR] states that:
archlinux-java-run is a helper script used to launch Java applications that have specific demands on version or provider of the used JVM. Options can be arbitrarily combined and archlinux-java-run will try to find a suitable version. If the user's default JVM is eligible, it will be used. Otherwise, if multiple eligible versions are installed, the newest Java generation is used. If multiple packages are available for this version, the one corresponding to the user's default JVM is used.
By default, archlinux-java-run will execute a suitable version of java with the given JAVA_ARGS. When run with -j|--java-home, it just prints the location of a suitable java installation so that custom commands can be run. When run with -e|--exec, it will run EXEC_CMD in an environment where $JAVA_HOME and $PATH is set so that the appropriate Java version is used.
If I am interpreting things right, this issue should no longer cause problems. (Please correct me if I am wrong.)
Offline