Thanks Tom! I'll definitely take a look at these links and see if there is a path in that direction for us.
There are two problems that I have with going to pure Eclipse 4 and they are why we have relied on the compatibility layer for far longer than I would prefer, to be honest. They are:
1.) The ICE product uses org.eclipse.platform.ide so that we "inherit" all of capabilities of that version of Eclipse in our own. (See
https://github.com/eclipse/ice/blob/master/org.eclipse.ice.repository/ice.product for reference.) I would liken this to how there are various flavors of Linux that just sit on top of more basic flavors. From what I can tell, this won't work with a pure E4 application and I haven't seen any tutorials or documentation on how to simply extend an existing E4 workbench.
2.) We use Eclipse Forms. Lars Vogel told me that Forms were moved to E4 in Kepler, but I haven't seen any good documentation yet on the differences between the API for 3.x and 4.x. I assume that it is as simple as
@Inject
IManagedForm form;
or something, but I just haven't seen a good example yet and I'm not keen on trying because I haven't figure out if #1 is an actual problem yet.
If you have any thoughts on these I would be much obliged. Relying on the 3.x API is really kicking us in the nuts when it comes to UI testing and even mockups with WindowBuilder for that matter.
One thing that would probably convince me that we need to focus on JavaFX with all due haste would be if JavaFX applications worked on the web either via something like the GTK Broadway backend (which freezes with SWT) or some other technology, but not anything based on applets. Getting ICE on the web is one of our big strategic goals. Here's a pic of ICE running on the web using Broadway,
https://twitter.com/jayjaybillings/status/651761614593654784.
I'm at ECE this week. Want to meet in person?