What does this mean for the future of JavaFX on iOS?
Tobi
tobi at ultramixer.com
Tue Apr 19 07:43:42 UTC 2016
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.vos at 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 <steve at 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.bembrick at 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.
>>
More information about the openjfx-dev
mailing list