Richard在社区中回复怎么实现fx移植到手机中

In the meantime we could discuss the main technical challenges to bring Java(FX) to Android, iOS and Windows 8:

1. Porting JavaFX glass/prims to iOS (OpenGL ES2), Android (???) and Windows 8 (DirectX???)

You actually will end up wanting to use OpenGL ES2 on both iOS and Android (having done the comparisons, the Prism stack on ES2 on Android is as fast or faster than native android graphics). On Windows 8, you use Direct3D the same as on Windows desktop, but you have to use WinRT instead of Win32 for the windowing etc. So there is definitely porting work on the Glass/Prism layer for Windows.

2. Bundle Java/OpenJDK within the app so that it's only one binary (static linking, no dynamic library loading!) (keywords: AOT (ahead of time compiler), Java-to-native-compiler, OpenJDK zero, shark, JNI, ...)

This is actually the biggest challenge IMO (in fact there is a thread on OpenJDK about porting OpenJDK to Android). I don't know off the top of my head if the JavaSE Embedded VM is open source -- I thought it was, or it was planned to make it so, but I could be wrong. In any case, getting a VM that runs on the platform is easy enough, getting JavaSE class libraries which pass the TCK is where I expect the majority of the work to be (porting FX to those platforms is fairly straightforward and with all the performance work we've already done in 8, you're starting from a pretty good place in terms of performance).

There are some interesting VM options you could give a try, such as Excelsior Jet or even XMLVM or LLVM. You might want to give a look to XMLVM, its kind of wild. You don't need AOT on Android, but you will on WinRT & iOS.

3. Shrinking JDK to a minimum (10MB instead of 140MB)

Actually you don't care about the JDK, but the JRE. Now, we've got the JRE + JavaFX down to about 20MB I think, but if you use an aftermarket tool like ProGuard then you can strip out methods and such you don't use, not just classes. FossilGame for iOS was down to 18MB for the entire app, 20MB with retina splash screen using this technique. One big part of this is getting the SE Embedded VM (or some other VM) which is small, even with AOT. That, I suspect, will be a technical challenge.

4. native look and feel (skin, css, ...) and native looking components (e.g. date chooser on iOS, lists, tab bar, navigation, ...)

This is dead easy and can all be done via CSS. See the blog post on FX Experience where Jasper does skinning of buttons, and includes some Windows / iOS buttons. Also, the JavaOne scheduler app (which is open source in the OpenJFX 8 repos) we did an entire popover control with skinning etc so it looks like native iOS popovers.

5. access to native features (like Phonegap/Cordova do it) like camera capture, geolocation, music library access on tablets, ...)

Ya, right now just use JNI. We played with something more like the underlying mechanism that Eclipse uses which generates Java classes to call into various APIs but doesn't have hardly any native code, but it isn't released anywhere. Some APIs would be worth having a cross platform implementation, but honestly for most of these things, you want to have every single capability of the host platform available so that you can get really good, deep, native integration. So I would expect to have an iOS package with camera, geolocation, etc APIs available, and an Android package with their APIs, etc. Then maybe a generic package with the least-common-denominator. I don't know, haven't looked at the specifics.

Also, you're going to want to be able to embed native controls inside FX to be able to do things like host advertisements in the application. That will require some work on Glass / Prism when it is open sourced.

Richard