Why are there limitations on the "embedded" port of javafx to begin with? Are there technical reasons for it?
If you think about it, "It's arm, so it's embedded. It's x86 so it's desktop" doesn't make much sense... (atom is embedded, and there are arm windows netbooks that are not). Anyway, as a workaround, can't openjfx simply be compiled on an arm host (so no cross compilation is required) and as such generate the missing libraries? Qemu with an arm vm can be used to do that on an x86 host for example. On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici < fabrizio.giud...@tidalwave.it> wrote: > On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick < > felix.bembr...@gmail.com> wrote: > > I really admire guys like this and wish that my own personal circumstances >> enabled me to get involved in a similar way but my main concern is that >> the >> "community" required to make JavaFX truly viable on iOS, Android and ARM >> needs to be about 50-100 times bigger than it currently is. Without an >> > > It's my concern too. At this point we're at 20 years of Java, and I lived > them from the very beginning. The idea "the community will fix it" is a > déjà vu that, unfortunately, says that in the past the thing didn't work > many times. > > This doesn't mean I'm necessarily in a fatalistic mood. When my RPI2 > arrives, I'll try the option you and others suggested. > > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it >