JavaFX port to iOS/Android status

[Richard Bair]

Hi Dan!

> Can you elaborate on what code is being released and what is not? I guess I was more or less expecting a ready to use sdk of sorts but I take it that was optimistic? 

I thought my blog post was pretty clear on this point: http://fxexperience.com/2013/02/february-open-source-update/

"A few years ago at JavaOne 2011 we showed a demo of JavaFX running on Android and iOS devices. This was a proof-of-concept which has two essential elements. The first is a port of the Windowing / Graphics layer of JavaFX (Glass & Prism) to use iOS & Android APIs. This is what we are open-sourcing, nothing more nor less. We are not providing a JVM for these platforms, nor am I aware of any such plan, so it’s not in any way a complete solution. Nor do we have a plan for releasing these ports in any release. We’re just opening up JavaFX code to the Java community for further experimentation."

> What is involved in 'porting' the 'VM' (as I understood it, you have JFX now as part of the VM so a little surprised we're making a distinction again)?

No, JavaFX is part of the *JDK* and the *JRE*, but not the JVM. There are many JVM's in the world, the most popular one being the Oracle JVM, but there are others. A JVM simply implements this specification: http://docs.oracle.com/javase/specs/

http://www.azulsystems.com/products/zing/virtual-machine
http://oss.readytalk.com/avian/
http://www.xmlvm.org/overview/
http://openjdk.java.net/projects/zero/
http://icedtea.classpath.org/wiki/ZeroSharkFaq

And many more. Some of these already work on iOS and Android, others don't. A port of JavaFX to another platform includes:
	- A version of Glass & Prism that can run (fonts, graphics, windowing, etc)
	- A JVM to run on
	- A minimal set of class libraries (such as java.util.collections)

The first of these is what our project is responsible for, and that code we are releasing in its entirety. But OpenJFX is not responsible for the VM or the Java class libraries.

> How do you know whatever it is you are releasing is iOS/android friendly if you haven't got it actually running on a platform (and if you have, why not just release that full code)?

We've had it running, and shown it at JavaOne a couple years ago. I can't answer the second question.

> Is the iOS/Android support only going to be relevant to the OpenJDK and not really the Oracle JDK? How does it all fit together. 

As I mentioned in the blog post (and subsequently on this list), we're releasing our prototypes. If it is going to become something real, the community is going to have to provide the missing pieces.

> Maybe the best way to answer that would be to answer: How do you envisage a developer building an iOS/Android app? From the sounds of it we will have to download a community built iOS version of openjdk (once someone makes this and makes it available for download) and then hand assemble a deployment bundle from this and our app code, and then manually upload to the app store?

Yes. I don't see any reason why the fxpackager (or replacement thereof) cannot create the bundles for you, but you have to manually upload it to an app store in any case (thanks Apple!) and you will have to feed it a version of OpenJDK that has been built with a VM that will work on the platform of choice. Or do a port of FX to Android that doesn't need a VM and just uses Dalvik. BTW, I think starting up a BitBucket repo for these ports would be an awesome way to go. And if somebody gets really hot on this stuff and contributes a lot back, they can be "promoted" to a full-fledged committer and just put the patches for iOS / Android (that are OpenJFX related) directly back into the code base. The JVM porting stuff and such will necessarily have to be outside of OpenJFX (either as another project within OpenJDK subject to all the OpenJDK bylaws etc, or as a free-wheelin' GitHub or BitBucket project).

So what we're not doing is just dumping this code out there and washing our hands of it. Basically what it comes down to is that we aren't funded to work on the iOS / Android stuff and make it production quality (with testing, documentation, and the whole bit), so any work we do is on our own time and our own dime just like everybody else. But we're passionate about it. The problem is that because we were doing this all internally we just used JDK 8 binaries that were available to us to prototype on, but as I mentioned in my blog those aren't being released, so in the meantime nobody will actually be able to ship android / iOS apps until somebody gets a VM that can run FX and start the performance tuning effort (which will likely be different for that VM than for the one we had been playing with).

That's where having somebody brilliant like a Landon Fuller who just gets in there and gets the job done is key. If people really care about FX on iOS / Android, then somebody will step up.

> I take it that tools for building deployment bundles won't be part of the jdk packaging tools and the community will also have to come up with the stuff needed to get it all app store friendly? 

I'm sure those patches could go into the fxpackager, but Oracle isn't funding Android / iOS work so either engineers have to do it on their own time or the community will have to do that.

> And then what about phone specific things like accessing signals from the OS like when an app is suspended, or sending an alert from the background, etc, and things like accessing the camera or the contacts list on the phone? Where does this all come into it and is this Oracle's or the community's job?

Its the communities port, so the community will do the job. It really isn't that difficult (this is the easy stuff -- performance work is where all the hard work lives).

> I'm probably not the person for the 'porting' work but I am interested in making the maven plugin support iOS/Android assemblies. I'm pretty vague on exactly what that would involve at this stage.

I'm sure once somebody gets a VM up and running, the rest of it will come together very quickly and at that point the requirements will be pretty clear.

Cheers
Richard