JOGL incompatible with SWT 4.21

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

JOGL incompatible with SWT 4.21

PeterC-DLS
Hi all,

We updated the target platform to 2021-09 for our Eclipse RCP application that uses JOGL (via Jzy3d) and found an issue.

When JOGL's SWTAccessor class is loaded (for a NewtCanvasSWT or GLCanvas), it initializes some field to point to methods in SWT's internal classes. The recent release of SWT 4.21 separated some gtk methods off to gtk3 and gtk4 specific bindings. This breaks the initialization code when looking for gtk_widget_get_window.

The patch below fixes this. I can provide a PR on https://github.com/sgothel/jogl if that's more convenient.

Best regards,
 Peter


---8<---
--- SWTAccessor.java.orig 2022-02-16 10:22:07.702204475 +0000
+++ SWTAccessor.java 2022-02-16 10:25:38.589674850 +0000
@@ -95,6 +95,7 @@
 
     private static final String str_OS_gtk_class = "org.eclipse.swt.internal.gtk.OS";    // used by earlier versions of SWT
     private static final String str_GTK_gtk_class = "org.eclipse.swt.internal.gtk.GTK";  // used by later versions of SWT
+    private static final String str_GTK3_gtk_class = "org.eclipse.swt.internal.gtk3.GTK3";  // used by later versions of SWT (4.21+)
     private static final String str_GDK_gtk_class = "org.eclipse.swt.internal.gtk.GDK";  // used by later versions of SWT
     public static final Class<?> OS_gtk_class;
     private static final String str_OS_gtk_version = "GTK_VERSION";
@@ -124,6 +125,8 @@
     private static final String str_gdk_window_set_back_pixmap = "gdk_window_set_back_pixmap";
     private static final String str_gdk_window_set_background_pattern = "gdk_window_set_background_pattern";
 
+    private static final int SWT_VERSION_4_21 = 4946;
+
     private static final VersionNumber GTK_VERSION_2_14_0 = new VersionNumber(2, 14, 0);
     private static final VersionNumber GTK_VERSION_2_24_0 = new VersionNumber(2, 24, 0);
     private static final VersionNumber GTK_VERSION_2_90_0 = new VersionNumber(2, 90, 0);
@@ -261,7 +264,12 @@
                 _gtk_version = GTK_VERSION(field_OS_gtk_version.getInt(null));
                 m1 = cGTK.getDeclaredMethod(str_gtk_widget_realize, handleType);
                 if (_gtk_version.compareTo(GTK_VERSION_2_14_0) >= 0) {
-                    m4 = cGTK.getDeclaredMethod(str_gtk_widget_get_window, handleType);
+                    if (SWT.getVersion() < SWT_VERSION_4_21) {
+                        m4 = cGTK.getDeclaredMethod(str_gtk_widget_get_window, handleType);
+                    } else {
+                        Class<?> cGTK3 = ReflectionUtil.getClass(str_GTK3_gtk_class, false, cl);
+                        m4 = cGTK3.getDeclaredMethod(str_gtk_widget_get_window, handleType);
+                    }
                 } else {
                     m3 = cGTK.getDeclaredMethod(str_GTK_WIDGET_WINDOW, handleType);
                 }
---8<---
Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

Martin
Thanks for sharing this.

When I added natives for M1 / ARM64, I also had to add this SWT jar. Were you able to build and run without updating any SWT jar?

Without any promise, there is a chance I rebuild JOGL soon. Having your PR on https://github.com/jzy3d/jogl would be helpful to integrate it in this release, so do not hesitate to push your work there.



Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

PeterC-DLS
This post was updated on .
It works in a simple JUnit test but not in a plugin test owing to the Equinox class loader not finding the gtk3 package. I think the SWT gtk jar needs to export org.eclipse.swt.internal.gtk3.

Edit: here's the upstream bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=577874
Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

Alexis Drogoul
Hi Peter,

Now that the upstream bug in SWT allows you to test your patch, does it work in a "regular" Equinox plugins scenario ? And if so, have you been able to regenerate JOGL ? Or how do you plan to use your fix ?

Any information appreciated as I am facing the exact same issue, and i have not decided yet what to do (wait for an "official" 2.4 release, use an "unofficial build" like the one produced by Martin, build our own versions... ?)

Cheers

Alexis

Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

Alexis Drogoul
Hi,

Just to report that I have been able to run JOGL on Eclipse 4.23 (2022-03) using the fix posted by Peter. Being in a regular Equinox/OSGI environment, I only had to duplicate SWTAcccessor.java, fix it, add it to the sources of the plugin where the JOGL libraries reside and voila ! this class is loaded by the ClassLoader instead of the one buried in JOGL jars. Obviously a temporary solution, but better than nothing for those who do not want to recompile JOGL or wait for a new version...

Thanks guys !
Alexis

Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

Marcel
In reply to this post by PeterC-DLS
I had the same error on Ubuntu, Eclipse 4.23 and successfully applied your patch after reading this post.

So a big thank you from my side!

Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

PeterC-DLS
In reply to this post by Alexis Drogoul
Hi all, Thanks for the feedback. I've add a PR sgothel/jogl#108. Best regards, Peter
Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

gouessej
Administrator
It's not the right place to fill bug reports, Github is only used as a mirror. You have to fill a bug report here:
https://jogamp.org/bugzilla/

If you don't have an account, contact me in private, I'll create one for you.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

Alexis Drogoul
In reply to this post by Alexis Drogoul
Alexis Drogoul wrote
Hi,

Just to report that I have been able to run JOGL on Eclipse 4.23 (2022-03) using the fix posted by Peter. Being in a regular Equinox/OSGI environment, I only had to duplicate SWTAcccessor.java, fix it, add it to the sources of the plugin where the JOGL libraries reside and voila ! this class is loaded by the ClassLoader instead of the one buried in JOGL jars. Obviously a temporary solution, but better than nothing for those who do not want to recompile JOGL or wait for a new version...

Thanks guys !
Alexis
Seems like SWT strikes again. Testing this solution againstSWT 4.26 (which comes with Eclipse 2022-12) fails with an error in SWTAccessor (either the patched one or the original one) under Linux (works well on Windows and macOS)

Anyones has a clue about what has been changed in the access to GTK in this version ?
Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

gouessej
Administrator
Maybe we have to take into account GTK 4 specific class in SWTAccessor. Moreover, you might have to use --add-opens with Java >= 9.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

Martin
In reply to this post by Alexis Drogoul
Hi Alexis,

I think we should try looking for explanations around this version bump commit in SWT.

Could you share the error message you encounter? That would help pointing to SWT classes and identify which class history to read...

Behind this, the bad news is that SWTAccessor design does not easily allow to fix JOGL by overriding : most of this class work is triggered in the class initialization without any other caller than the classloader. I think the fix should require a JOGL rebuild.

Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

RoiArthurB
Hi Martin and  gouessej,

I'm working with Alexis and here's the error stack we're having as requested by Martin:

java.lang.ExceptionInInitializerError
        at com.jogamp.newt.swt.NewtCanvasSWT.<init>(NewtCanvasSWT.java:136)
        at ummisco.gama.opengl.view.GamaGLCanvas.<init>(GamaGLCanvas.java:101)
        at ummisco.gama.opengl.view.SWTOpenGLDisplaySurface.<init>(SWTOpenGLDisplaySurface.java:145)
        at gaml.additions.opengl.GamlAdditions.lambda$4(GamlAdditions.java:65)
        at msi.gama.common.interfaces.IDisplayCreator$DisplayDescription.create(IDisplayCreator.java:58)
        at msi.gama.common.interfaces.IDisplayCreator$DisplayDescription.create(IDisplayCreator.java:75)
        at ummisco.gama.ui.utils.SwtGui.createDisplaySurfaceFor(SwtGui.java:284)
        at ummisco.gama.opengl.view.OpenGLDisplayView.createSurfaceComposite(OpenGLDisplayView.java:47)
        at ummisco.gama.ui.views.displays.LayeredDisplayView.ownCreatePartControl(LayeredDisplayView.java:217)
        at ummisco.gama.opengl.view.OpenGLDisplayView.ownCreatePartControl(OpenGLDisplayView.java:122)
        at ummisco.gama.ui.views.GamaViewPart.createPartControl(GamaViewPart.java:263)
        at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPartControl(CompatibilityPart.java:158)
        at org.eclipse.ui.internal.e4.compatibility.CompatibilityView.createPartControl(CompatibilityView.java:155)
        at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:365)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:58)
        at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:995)
        at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:960)
        at org.eclipse.e4.core.internal.di.InjectorImpl.internalInject(InjectorImpl.java:140)
        at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:403)
        at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:330)
        at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:202)
        at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:91)
        at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:60)
        at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:42)
        at org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer.createWidget(ContributedPartRenderer.java:132)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:995)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:659)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$1.run(PartRenderingEngine.java:544)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:528)
        at org.eclipse.e4.ui.workbench.renderers.swt.ElementReferenceRenderer.createWidget(ElementReferenceRenderer.java:73)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:995)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:659)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:763)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:728)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:712)
        at org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer.showTab(StackRenderer.java:1208)
        at org.eclipse.e4.ui.workbench.renderers.swt.LazyStackRenderer.postProcess(LazyStackRenderer.java:116)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:677)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:763)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:728)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:712)
        at org.eclipse.e4.ui.workbench.renderers.swt.SWTPartRenderer.processContents(SWTPartRenderer.java:72)
        at org.eclipse.e4.ui.workbench.renderers.swt.SashRenderer.processContents(SashRenderer.java:150)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:673)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:763)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:728)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:712)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.subscribeTopicToBeRendered(PartRenderingEngine.java:161)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:58)
        at org.eclipse.e4.core.di.internal.extensions.EventObjectSupplier$DIEventHandler.handleEvent(EventObjectSupplier.java:92)
        at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:205)
        at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:203)
        at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1)
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
        at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151)
        at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:133)
        at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:75)
        at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:44)
        at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:55)
        at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:63)
        at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:424)
        at org.eclipse.e4.ui.model.application.ui.impl.UIElementImpl.setToBeRendered(UIElementImpl.java:314)
        at org.eclipse.e4.ui.workbench.addons.cleanupaddon.CleanupAddon.subscribeRenderingChanged(CleanupAddon.java:334)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:58)
        at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:183)
        at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:133)
        at org.eclipse.swt.widgets.Display.syncExec(Display.java:5960)
        at org.eclipse.e4.ui.workbench.swt.DisplayUISynchronize.syncExec(DisplayUISynchronize.java:34)
        at org.eclipse.e4.ui.internal.di.UIEventObjectSupplier$UIEventHandler.handleEvent(UIEventObjectSupplier.java:64)
        at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:205)
        at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:203)
        at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1)
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
        at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151)
        at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:133)
        at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:75)
        at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:44)
        at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:55)
        at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:63)
        at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:424)
        at org.eclipse.e4.ui.model.application.ui.impl.UIElementImpl.setToBeRendered(UIElementImpl.java:314)
        at org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.showElementInWindow(ModelServiceImpl.java:655)
        at org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.showElementInWindow(ModelServiceImpl.java:662)
        at org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.bringToTop(ModelServiceImpl.java:624)
        at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.delegateBringToTop(PartServiceImpl.java:790)
        at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.activate(PartServiceImpl.java:761)
        at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.activate(PartServiceImpl.java:683)
        at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.activate(PartServiceImpl.java:678)
        at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.showPart(PartServiceImpl.java:1255)
        at org.eclipse.ui.internal.WorkbenchPage.showPart(WorkbenchPage.java:1247)
        at org.eclipse.ui.internal.WorkbenchPage.busyShowView(WorkbenchPage.java:1235)
        at org.eclipse.ui.internal.WorkbenchPage.lambda$11(WorkbenchPage.java:4229)
        at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:74)
        at org.eclipse.ui.internal.WorkbenchPage.showView(WorkbenchPage.java:4227)
        at ummisco.gama.ui.utils.SwtGui.lambda$0(SwtGui.java:225)
        at ummisco.gama.ui.utils.WorkbenchHelper.run(WorkbenchHelper.java:148)
        at ummisco.gama.ui.utils.SwtGui.internalShowView(SwtGui.java:216)
        at ummisco.gama.ui.utils.SwtGui.showView(SwtGui.java:255)
        at msi.gama.outputs.AbstractDisplayOutput.lambda$0(AbstractDisplayOutput.java:63)
        at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
        at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:132)
        at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:5040)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4520)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1155)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1046)
        at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155)
        at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:643)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
        at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:550)
        at msi.gama.application.Application.start(Application.java:156)
        at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:136)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:402)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:659)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:596)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1467)
        at org.eclipse.equinox.launcher.Main.main(Main.java:1440)
Caused by: com.jogamp.nativewindow.NativeWindowException: java.lang.NoSuchMethodException: org.eclipse.swt.internal.gtk.GDK.gdk_window_set_background_pattern(long,long)
        at com.jogamp.nativewindow.swt.SWTAccessor.<clinit>(SWTAccessor.java:387)
        ... 140 more
Caused by: java.lang.NoSuchMethodException: org.eclipse.swt.internal.gtk.GDK.gdk_window_set_background_pattern(long,long)
        at java.base/java.lang.Class.getDeclaredMethod(Class.java:2675)
        at com.jogamp.nativewindow.swt.SWTAccessor.<clinit>(SWTAccessor.java:382)
        ... 140 more
My thoughts is that the problem may, indeed, comes from the new GTK 4, but it also can come from some rework to be compatible with Wayland
Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

RoiArthurB
Hi all,

Just a quick update, I did try to compile our software with different version of SWT, and none of them works above Eclipse 2022-03 (SWT 4.21)...

So I did a git diff between every files used in the patched SWTAccessor between SWT 4.21 and 4.22 (the problem should comes from here I guess), which is here : https://pastebin.com/miWipQJ3 

Most of the modifications are in the file `Display.java`, but I can't really point out what could be breaking... Maybe something about callbacks ?

I also made another diff with those same files but comparing SWT 4.21 and 4.26 (current latest release) : https://pastebin.com/xNawYsZs
Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

Martin
Hi,

What I find surprising is that the root cause of your problem is located here according to the stack trace

Caused by: java.lang.NoSuchMethodException: org.eclipse.swt.internal.gtk.GDK.gdk_window_set_background_pattern(long,long)
        at java.base/java.lang.Class.getDeclaredMethod(Class.java:2675)
        at com.jogamp.nativewindow.swt.SWTAccessor.<clinit>(SWTAccessor.java:382)

But there actually nothing related to getDeclaredMethod(..) or gdk_window_set_background_pattern at line 382 of SWTAccessor

It should rather be line 281 if you work with Peter's patch, ... same if you are using the non patched SWTAccessor.

Anyway, this suggests gdk_window_set_background_pattern disappeared, which is confirmed by reading the diff you made between 4.21 and 4.22.

So a fix would be to change

if (_gtk_version.compareTo(GTK_VERSION_2_90_0) >= 0) {
        mb = cGDK.getDeclaredMethod(str_gdk_window_set_background_pattern, handleType, handleType);
} else {
        ma = cGTK.getDeclaredMethod(str_gdk_window_set_back_pixmap, handleType, handleType, boolean.class);
}

by something like this

if (_gtk_version.compareTo(GTK_VERSION_2_90_0) >= 0) {
    if (_gtk_version.compareTo(GTK_VERSION_2_21_0) <= 0)
        mb = cGDK.getDeclaredMethod(str_gdk_window_set_background_pattern, handleType, handleType);
} else {
        ma = cGTK.getDeclaredMethod(str_gdk_window_set_back_pixmap, handleType, handleType, boolean.class);
}

(but you should check wether str_gdk_window_set_back_pixmap is required or not as of 4.22).

Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

RoiArthurB
Hi,

Thanks a lot for your quick answer.

Martin wrote
It should rather be line 281 if you work with Peter's patch, ... same if you are using the non-patched SWTAccessor.
We are using an adapted version of Peter's patch that you can find here.

Martin wrote
So a fix would be to change [...]
I did a stupid copy/paste replacing the code you pointed to me by the one you gave me, and it works on X11 !! 🥳

However, as the accessor check if the application is using the X11 backend, it crashes our soft' if ran using Wayland with this error log :
Loading redefined SWTAccessor
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fe804ff5624, pid=116734, tid=116735
#
# JRE version: OpenJDK Runtime Environment (17.0.5+1) (build 17.0.5+1)
# Java VM: OpenJDK 64-Bit Server VM (17.0.5+1, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  [libX11.so.6+0x3a624]  XQueryExtension+0x64
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h" (or dumping to /home/roiarthurb/Documents/GAMA/gama/core.116734)
#
# An error report file with more information is saved as:
# /home/roiarthurb/Documents/GAMA/gama/hs_err_pid116734.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
It's a bit frustrating, but I guess it's pretty normal as JOGAMP only been dev for X11 compatibility so far 🤔🤔
Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

Martin

Nice step! Maybe it is worth asking to the developers involved in the changes you pointed in your diff to get sure our change is fully relevant for GTK... they'll probably answer through github ticket!

But more importantly Could you share the core dump file (.log) to better understand what's happening? I see no reason for JOGL to fail on wayland. I have seen JOGL working in several remote desktop scenarios...



Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

gouessej
Administrator
I don't remember the details but Wayland isn't supported out of the box, a contributor did this:
https://github.com/udevbe/wayland-java-bindings
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

RoiArthurB
In reply to this post by Martin
Martin wrote
Could you share the core dump file (.log) to better understand what's happening?
Here you go : https://pastebin.com/vJTGjVst
Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

Martin
In reply to this post by Alexis Drogoul
Hi Alexis,

I red this message again today and found that it is a very good idea to "override" classes in JOGL that have a static initializer.

I did something similar while debugging something in JAWTUtil class. Simply copy pasting JAWTUtil in the project from which the main program is ran ensures my JAWTUtil copy get loaded first, which then prevent JOGL from loading the original JAWTUtil.

Do you think this kind of hack could be reliable? Are there scenarios where class loading could happen differently and this trick fail? I am mainly thinking of cases where class loading happens differently on the customer computer :)
Reply | Threaded
Open this post in threaded view
|

Re: JOGL incompatible with SWT 4.21

gouessej
Administrator
No
Julien Gouesse | Personal blog | Website
12