Until yesterday I had the following dev environment perfectly working:
- Ubuntu LTS 20.04
- Eclipse (in Snap)
- JavaFX (JARs and *.so’s in local Folder, –module-path configured in project)
Yesterday "snap" came up and said: stop the app to let updates be installed … I think, it was talking about Eclipse.
After having Eclipse restarted, my JFx application complained about "glass not being in Java Lib Path". I know this error from Ubuntu LTS 22.04 and could not fix it a month ago (when repairing all paths, you’ll end up by some lib ONLY accepting a glibc 2.33, but I already have 2.35) … that’s why I rolled back to 20.04 a month ago :-/
Now this bug hits me again in 20.04 via snap updates.
I drilled the behavior down to having a project’s debug commandline, that shows above error. It starts to work as soon as I change that cmd line to NOT use Eclipse’s build-in JRE located in Eclipse’s snap path. Result: it only works outside of Eclipse now.
Question: does anybody know, how to find the connection in Eclipse’s config, that causes Eclipse’s Java to use the (obviously freshly installed) snap-version of openjfx (19+11) instead of a working and properly configured (old) local JFx version?
That version seems buggy and does NOT work for Ubuntu 22.04 also in an out-of-the-box installation.
^5
Synopsis
//EDIT: in case this matters … just saw, that in /snap/eclipse there are TWO versions (60 and 61), with current pointing to 61, BUT the debug-commandline path, showed by Eclipse, uses 60 (not "current and not 61). When I manually launch the Eclipse in 61, it appears completely fresh, without default workspace path and without any plugins.
So when using (on commandline) the java from there, it also works, having no JavaFX plugin under Eclipse dir "61".
I don’t reaaly get the idea of a "current" that is unconfigured and all paths pointing to old dir 60 … obviously my lack of knowledge about snap :-/
2
Answers
I found a workaround: I added an external Java Execution Environment (the system owned JRE) and configured the project to use that. Now it works again from within Eclipse using the old JFX in my home dir - even the debugger is working fine :-)
But this is no clean solution. I want to have in MY influence, what stuff the internal Java Environments of Eclipse are using. I cannot accept, that the internal JREs are magically connected to some magically appearing snap-app (openjfx 19/11) without even a notice to me or better the option to say "no" to either new snaps or snap updates.
well … talking to myself 🙂
LAST update: some background rollback appears to have sent me to the Test-VM with Ubuntu 22.04 instead of my active VM with Ubuntu 20.04.
So my posted workaround can be regarded as working for those that desparately try to get JavaFX working under 22.04 🙂
So the "problem" I thought to see concerning 20.04 does not exist … sorry.