JDK-8156491 : Autodetect GTK version for JFX
  • Type: Bug
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • Submitted: 2016-05-07
  • Updated: 2016-12-22
  • Resolved: 2016-12-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Fixed
Related Reports
Relates :  
JDK-8157002 - Toggle gtk version if SWT used via FXCanvas
Relates :  
JDK-8143596 - FXCanvas does not forward touch gestures to embedded scene
Relates :  
JDK-8163496 - Rework Glass GTK to correct gtk3 structure sizes
Description
Investigate if we can auto detect any GTK version in use before loading  GTK in JFX.
Comments
Changeset: 4d72bb1f6d81 Author: ssadetsky Date: 2016-12-22 13:16 -0500 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/4d72bb1f6d81 8156491: Autodetect GTK version for JFX Reviewed-by: ddhill, kcr ! modules/javafx.graphics/src/main/native-glass/gtk/launcher.c
22-12-2016
Could you, please, push it?
22-12-2016
Thanks, looks good.
22-12-2016
http://cr.openjdk.java.net/~ssadetsky/8156491/webrev.02/
22-12-2016
The logic looks good. Testing looks good. Two comments on the code itself: 1. There is an unconditional call to "fflush(stdout)" that needs to be qualified by gtk_versionDebug (or simply moved to right after the printf in the for loop, since performance isn't a concern in this case). 2. Minor nit: There should be a space after the "for" and before the "(" in: for(i = 0; use_chain[i] && !found; i++) { +1 pending the fixes above (no need for a new webrev if those are the only changes).
21-12-2016
http://cr.openjdk.java.net/~ssadetsky/8156491/webrev.01/
16-12-2016
JDK-8163496 is pushed ! (finally)
15-12-2016
Okay, David. I will create a new webrev after you push JDK-8163496.
24-11-2016
Semyon, In general I like what I see here. But.... as part of JDK-8163496, that file is going away, and at least some of the functionality is relocated into a new launcher.c Kevin and I have said that JDK-8163496 is likely to go in the first week in December (I have vacation next week). I think it would be quicker if you rework your patch to go over the top of JDK-8163496, and push after that is committed.
23-11-2016
http://cr.openjdk.java.net/~ssadetsky/8156491/webrev.00/
23-11-2016
[~ssadetsky] This bug was filed as a follow-up so as not to hold up getting the JEP done for FX. As you say, JDK-8157002 might be a good idea anyway to cover the case when swt.jar is on classpath, but loaded after glass is loaded.
22-11-2016
I see now. For some reasons JEP-283 doesn't implement native version detection using RTLD_NOLOAD for JFX like it does for JDK. Why it was not implemented as part of the JEP? That should be fixed of cause. Probably JDK-8157002 is not needed at all. It's my fault. Or JDK-8157002 covers the scenario when swt.jar is on the classpath, but before it is loaded by the ClassLoader its native libs cannot be detected? I kept in mind this scenario when I fixed it.
22-11-2016
No, this isn't resolved yet, which is one reason that JDK-8157002 is needed.
22-11-2016
Kevin, Hasn't this already resolved in JEP-283?
22-11-2016
If we can find a general solution for this, then it sill supersede JDK-8157002. Otherwise, we will at least need to fix that bug.
03-11-2016