On Wed, Apr 8, 2015 at 11:03 PM, Stefan Fuchs <snfu...@gmx.de> wrote:
> > But in all artificial restrictions to implement your own workarounds using > private apis its another minus on our assessment of the risks involved, > when investing in the javafx technology. Others are the diminishing plugin > support by browser vendors and a lack of commitment from oracle for growing > platforms like android or ios. > On the other side of the equation is unrestricted access of the > application to the local filesystem and cpu resources and the rich java > apis. > > Currently the equation still holds in favor of javafx, but is constantly > evaluated. > > *Exactly* the same situation here. I have been arguing against colleagues proposing an approach where we keep the non-UI code Java and make the UI using the native technologies similar to what robovm does for iOS APIs which works remarkably well but of course has its drawbacks compared to largely sharing the UI code across platforms but other obvious advantages. With each of these decisions making it harder to somehow get through the very long phase of JFX maturing, my case for porting to JFX falls apart more and more.
