| What bundle should I depend on for javafx.embed.swt.FXCanvas? [message #1766551] |
Fri, 23 June 2017 01:02  |
 Theodore Murdock
Messages: 5
Registered: January 2015 |
Junior Member |
|
|
I'm wondering what bundle one should depend on currently in order to have access to javafx.embed.swt.FXCanvas in an Eclipse plugin.
I'm in the process of switching a plugin from depending on a customized version of SWT_AWT + Albireo to instead use FXCanvas + SwingNode to display Swing components in Eclipse. (SWT_AWT + Albireo is deadlock prone, we've modified it over the years to remove synchronous calls between the SWT and AWT threads, but the bridge still causes some issues, such as tooltips being unreliable in SWT, which makes the FXCanvas approach very attractive.)
I gather, from what I've seen, that classloading FXCanvas is a bit complicated in osgi, but I was happy to see that you had put out an orbit bundle (org.eclipse.fx.javafx) that we could depend on to make sure it was available...but now it seems you've deprecated that bundle, as I'm seeing a warning to that effect when I debug our plugin.
I'm also seeing suggestions that the plugin dependency should instead be replaced with the VM argument -Dorg.osgi.framework.bundle.parent=ext
...is that command-line argument sufficient for all Eclipse installations, regardless of whether e(fx)clipse is installed, or is there a p2 orbit bundle that we must also depend on?
Does this change also mean it is necessary to require customers who install via our update site to modify their Eclipse.ini by hand if we switch to using FXCanvas?
|
|
|
|
| Re: What bundle should I depend on for javafx.embed.swt.FXCanvas? [message #1768696 is a reply to message #1766965] |
Fri, 21 July 2017 18:25  |
Theodore Murdock
Messages: 5
Registered: January 2015 |
Junior Member |
|
|
No, the SWT/AWT bridge - unless something has changed about the assumptions it makes in the last couple of years - is fundamentally broken, and should not be used as implemented for anything. SWT/AWT makes the assumption that it's safe for one of the two UI threads to make a blocking call on the other, so long as a blocking call from the other UI thread never occurs. This assumption is fundamentally false, because both UIs lock common native resources. On Windows, SWT/AWT uses a hack to pump the native event queue and tell Swing "you go first", but on OSX and Linux no such hack exists, so SWT/AWT regularly deadlocks.
Currently, we are using our own alternative to SWT/AWT (with the deadlock-producing assumption removed) together with our own version of the abandoned Albireo project, which fixes a few issues and makes life under the SWT/AWT bridge a bit more viable -- but not really as good as it should be. For example, tooltips stop working in Eclipse as soon as SWT/AWT starts up, and sometimes transfers of focus go wrong, such as the find dialog not gaining focus when it's opened, and losing its connection to the active editor.
Can FXCanvas also be used as an FX->SWT part? That's not how Oracle describes its use: http://docs.oracle.com/javafx/2/swt_interoperability/jfxpub-swt_interoperability.htm. I've successfully used it to embed FX content in SWT (by depending on the deprecated org.eclipse.fx.javafx bundle), and I know e(fx)clipse uses it internally also.
Using that in combination with embedding Swing in FX (which is a standard part of Java and doesn't need any fancy classloading to work properly), I find that things work a lot better, the tooltip issues and focus loss don't occur, and embedding FX in SWT is safe, because they made the correct assumption that communication between UI threads must always be via invokeLater and asyncExec.
Ideally, the SWT/AWT bridge should be replaced with something that uses (or itself be refactored to use) FXCanvas + SwingNode, but if that is to be done, it needs to be coordinated with e(fx)clipse, as I think it could potentially be unsafe to have two copies of FXCanvas class-loaded in the same process, unless its designers considered that possibility and wrote the side-effects of its interaction with the shared classes of JavaFX itself defensively.
This is also why I'd prefer to get FXCanvas as loaded by e(fx)clipse if possible.
If there's a better way to embed FX into SWT than using FXCanvas directly, I'm also open to that, I just want to reach the point at which I can say "add our update site, install, we'll find our dependencies via p2/orbit, done". I considered depending on e(fx)clipse itself to embed FX in SWT, but I initially thought it wasn't a part of the default Eclipse repository, and I thought I'd try to keep the dependencies minimal.
I also came across something that suggested installing e(fx)clipse isn't as simple as adding the plugin, that you also have to modify the vmargs in your eclipse launch script, is that the case? Why was org.eclipse.fx.javafx deprecated?
[Updated on: Fri, 21 July 2017 18:26] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02348 seconds
] 
Search
Help
Register
Login
Home
