Well I did ask Johan what AOT they are going to use instead of RoboVM but there has not be a response yet.
Let's face it, without highly optimised AOT, Java and/or JavaFX on mobiles is simply not viable which in turn implies that JavaFX itself is not even worth looking at... RIP. But I take Johan on his word that the demise of RoboVM will not negatively affect Gluon or its products and he has done absolutely amazing things throughout his career. So I am assuming he as a plan B. I really wish Gluon somehow took complete ownership of the entire OpenJFX project as JavaFX could not be in safer hands. > On 19 Apr 2016, at 17:43, Tobi <t...@ultramixer.com> wrote: > > Hi, > > in my opinion the abandonment of RoboVM is a very big step back for Java on > Mobile because there is NO real alternative to RoboVM. So it has definitely a > big impact on Gluon and JavaFX on Mobile. Gluon uses RoboVM 1.8 - and old > version of RoboVM which will be not developed anymore. So no serious company > will decide to use a technology which is winding down! > > So ok, what could Gluon do now? Using OpenJDK9 for iOS and Android? Currently > definitely not! OpenJDK9 for Mobile is in an experimental state and uses the > Zero interpreter! So the performance will be not acceptable until the OpenJDK > 9 provides the same level of AOT like RoboVM - or even better! > > What can we do now to reach the goal to develop modern mobile applications > with Java - instead of with Xamarian…? > > We need as soon as possible one or more companies to continue the development > of one of the RoboVM 1.8 forks (like BugVM) or merge the know how of RoboVM > with the current OpenJDK9 efforts… We need commitments of big companies to > Java like Oracle, Intel, IBM, SAP! We need the RoboVM team which breaks out > of Microsofts Xamarian world! In my dreams Niklas, Henric and their team take > the money of Xamarian and Microsoft and revive their baby „RoboVM“ in the > context of a fork based on open sourced RoboVM 1.8… Maybe with in a join > venture with Intel (concerning Intel’s Multi-OS engine) > > What do you think about it guys? What are your plans Niklas…? > > Best regards, > Tobi > > // > follow me on twitter: https://twitter.com/tobibley > <https://twitter.com/tobibley> > > > > >> Am 18.04.2016 um 19:15 schrieb Johan Vos <johan....@gluonhq.com>: >> >> Indeed, this doesn't have any impact on JavaFX. >> The Gluon tools are currently using the RoboVM AOT 1.8, which was the last >> open-source version. >> >> RoboVM delivered a whole set of products, including an AOT, but also a >> system that provides some JNI functionality, a set of bindings that create >> Java classes that have a 1-1 mapping to native iOS classes, and a whole >> "Studio" allowing developers to create applications. >> >> Only the AOT is relevant to us. We don't use the bindings, as we happen to >> have a great set of UI classes: the JavaFX platform. We don't need the >> studio, as we directly provide plugins for NetBeans, IntelliJ and Eclipse. >> >> The idea of JavaFX is to deliver a cross-platform UI for all devices. >> RoboVM took a different approach, as they mainly promoted creating an iOS >> specific UI (using the Java bindings to the native iOS UI components) and >> an Android specific UI. >> >> We had different views on a cross-platform UI (JavaFX) versus a >> platform-specific UI, but here is no doubt the RoboVM team consist of great >> developers and it is a real pity and shame they won't be able to continue >> working on their product. >> >> But for JavaFX and Gluon, it doesn't make a difference. >> >> - Johan >> >> >>> On Mon, Apr 18, 2016 at 6:52 PM, Steve Hannah <st...@weblite.ca> wrote: >>> >>> According to Gluon, they're not impacted by this. >>> https://twitter.com/GluonHQ/status/721784161728471041 >>> >>> >>> >>> On Mon, Apr 18, 2016 at 9:36 AM, Felix Bembrick <felix.bembr...@gmail.com> >>> wrote: >>> >>>> I just read this article which states that RoboVM is effectively >>>> "shutting down". >>>> >>>> https://www.voxxed.com/blog/2016/04/robovm/ >>>> >>>> Given that they seem to be a critical part of the puzzle that is making >>>> JavaFX viable on mobile platforms, what does this actually mean for that >>>> goal? >>>> >>>> Is there an alternative technology or product that can fill this void? Or >>>> is the final nail in the coffin for JavaFX to ever be a truly viable cross >>>> platform technology? >>>> >>>> Thanks, >>>> >>>> Felix >>> >>> >>> >>> >>> -- >>> Steve Hannah >>> Web Lite Solutions Corp. >
