JavaFX on iOS and Android: The real problem and challenge

Sven Reimers sven.reimers at gmail.com
Sat Nov 9 02:14:54 PST 2013 

So what seems more feasible?

a) trying to get AOT inside OpenJDK (and get it maintained as part of the
OpenJDK process) - I am sure there must be some interest in this from an
IoT perspective.

b) Do not use OpenJDk class libraries and make people duplicate work at
some other place?

My personal opinion is - go with a) and try to figure out the legal hassle
(I am sure there must be a way around the GPL problem, mabye similiar to
the class path exception?) and donate RoboVM Code to OpenJDK...

Just my personal 2cents

-Sven

P.S. Is there any way to get an answer from Oracle concerning their
position towards OpenJDK/JVm/Java and AOT?




On Sat, Nov 9, 2013 at 9:44 AM, Niklas Therning <niklas at therning.org> wrote:

> Here's a crazy idea for you guys: how about contributing to RoboVM instead
> and maybe, just maybe, it would one day become more than a one man project?
> ;-) I'm of course very aware of the problem you're facing with JFX+iOS and
> as I said to some of the Oracle guys at J1 I'm very tempted to making it an
> option to use the OpenJDK class lib with RoboVM and support invokedynamic.
> These are the major things missing from RoboVM in order to use it with a
> vanilla OpenJFX8 build (and not the jfx78 backport). I WILL do this work at
> some point but it's not at the top of my list of priorities. If I could get
> some help on other things I can get to it sooner.
>
> I'm a bit surprised that you're considering starting from scratch with a
> new project and not building on previous work. Is there something
> fundamentally wrong with RoboVM, something that cannot be fixed that is
> preventing you from using it? What would you gain from starting from
> scratch with OpenJDK? AFAIK there's no AOT compiler in OpenJDK. And you
> probably cannot reuse code from hotspot (like the GCs) since it's pure
> GPLv2 (no classpath exception) and it would contaminate the rest of the
> app's code and force it to be GPL as a whole since you have to link
> everything statically on iOS (note: this is my interpretation of the GPL,
> IANAL!).
>
> As for RoboVM being a "prototype", "experimental" and not "production
> ready". Yes, it's immature and there are bugs in there but every project is
> in the beginning (even OpenJDK subprojects ;-) ). It will evolve in time
> and the more people who use it and contribute the sooner it will mature.
> Also, all of those terms are subjective. I've stopped saying that it's not
> "production ready" myself because for some people it is ready! There are
> already apps in the App Store developed by others that are working fine and
> prove this (let me know if you're interested and I'll provide a list of
> those I'm aware of).
>
> In the long term we will provide professional services (support contracts,
> add-ons, etc) around the RoboVM open-source project. We hope that we can
> hire a team that can work on this full-time and build a healthy community
> around it. In the short term our biggest problem is resources, both in
> terms of man-power and financially. We've been contacted by some companies
> which would consider sponsoring this project. If you work for a company
> which would benefit from Java on iOS becoming a reality than please try to
> convince your management to sponsor. Who knows, if we would focus more on
> OpenJFX and OpenJDK maybe we could even get some help from Oracle? Perhaps
> start a petition in the JavaFX community to try to persuade Oracle into
> supporting RoboVM? Anyone up for it?
>
> /Niklas (the RoboVM guy)
>
>
> On Fri, Nov 8, 2013 at 10:36 PM, Richard Bair <richard.bair at oracle.com
> >wrote:
>
> > Totally, I think the normal process for this is to create a new OpenJDK
> > project, is it not? Can you take a look at the OpenJDK bylaws and report
> > back on the process? I think it would be awesome to do a port. Note that
> > there are a few OpenJDK ports already which have ARM support, you might
> > want to look there as a starting point?
> >
> > Richard
> >
> > On Nov 8, 2013, at 1:29 PM, Florian Brunner <fbrunner at gmx.ch> wrote:
> >
> > > Yes, I agree, we need professional JVM ports for iOS, Android and
> > Windows 8.
> > >
> > > @Oracle: Could you set up the according project sites for these 3
> > platforms on openjdk.java.net and document what exactly has to be done
> to
> > port OpenJDK (at least some kind of JavaFX compact profile e.g. without
> the
> > AWT stack) to these platforms? Also the Mercurial repository and the
> build
> > should be prepared.
> > >
> > > I think if there were an easy starting point it would lower the barrier
> > to work on these ports.
> > >
> > > -Florian
> > >
> > > Am Donnerstag, 24. Oktober 2013, 08.41:32 schrieb Tobias Bley:
> > >> Hello to the community,
> > >>
> > >> I read the last discussion about „JavaFX native look and feel“ and
> have
> > to get out of my mind the following:
> > >>
> > >> In my opinion the MAIN point is not „how to bring the native look and
> > feel to iOS/Android“, the real MAIN issue is: we need a professional
> JVM(!)
> > which works performant and reliable on iOS, Android and Windows 8! Only
> if
> > we have such a JVM, developers and companies are motivated to develop
> real
> > commercial apps with JavaFX and contribute stuff back to OpenJFX!
> > >>
> > >> RoboVM is a good „prototype“. Niklas is currently one of the most
> > important people for the JavaFX community. He and his company has build
> the
> > first and one and only real solution to deploy Java and JavaFX code to
> the
> > iOS platform! His work is really great! But: He is only one(!) person!
> This
> > kind of complex task I would expect from big companies like Oracle, IBM,
> > SAP or Twitter. But from this direction we don’t hear anything about it.
> > >>
> > >> It is not enough that people like Niklas (Trillian AB) or Matthias and
> > me (UltraMixer) are trying to bring JavaFX to iOS and Android. It’s all
> > experimental stuff! Yes, currently we can start JavaFX apps on a real
> > iPhone and iPad. And yes, we have managed to start JavaFX on a real
> Android
> > device using the Dalvik VM. BUT: this is not a long term solution and
> only
> > experimental! RoboVM on iOS uses the android class library instead of the
> > real Java = OpenJDK. Our „JavaFX on Android“ solution uses Google Dalvik
> VM
> > and the Android class library as well! So both solutions use the real
> Java
> > platform (=OpenJDK)!
> > >>
> > >> In my opinion there are only two solutions: 1) Oracle releases their
> > JVM for iOS and Android. 2) The „community“ starts a new company who
> > develops a professional, performant and reliable solution for „JavaFX on
> > iOS and Android“ which contains of a JVM and the 6 degrees Felix
> described
> > in his blog post, mainly native integration (API) and look and feel
> (skins,
> > native controls).
> > >>
> > >> Cheers,
> > >> Tobi
> > >>
> > >>
> > >>
> > >> Am 23.10.2013 um 22:30 schrieb Richard Bair <richard.bair at oracle.com
> >:
> > >>
> > >>> Yes, definitely.
> > >>>
> > >>>> On Oct 23, 2013, at 11:52 AM, Scott Palmer <swpalmer at gmail.com>
> > wrote:
> > >>>>
> > >>>> This is starting to sound like it may also partially address the
> > issue in the desktop space of supplying a native surface (the
> heavyweight)
> > to draw in that is part of the scene graph.  It may not be the ideal
> > solution, but could be useful for specific use cases, like a video
> preview
> > overlay. Would that make any sense?
> > >>>>
> > >>>>
> > >>>> Scott
> > >>>>
> > >>>>
> > >>>>
> > >>>>> On Tue, Oct 22, 2013 at 7:59 PM, Richard Bair <
> > richard.bair at oracle.com> wrote:
> > >>>>> To do this we need to either solve the auto-layer problem in the NG
> > nodes / Glass / Quantum, or we need to ask the app developer to use
> > SubScene and put all the native stuff in a single SubScene, and all
> > lightweight content above and below it. For the short term, we could use
> > the SubScene approach ("Just be careful and don't draw lightweight on top
> > of heavyweights unless you layer an entire sub scene above them") which
> is
> > probably a perfectly workable solution in the short term. Then somebody
> > just needs to write a set of skins (which can be done in an external
> > project) that map various UI controls directly to native controls. This
> > approach would allow people to have completely native controls while
> using
> > the FX API, or they can use the lightweight controls (with Modena or with
> > an iOS 7 skin or iOS 6 skin etc).
> > >>>>>
> > >>>>> I'm thinking about how to implement the auto-layer, and I'm not
> sure
> > of the best approach. It seems like you need to hook into the sync-time
> to
> > determine which nodes can be batched into the same layer, reusing
> previous
> > layers where possible. If there is a way to then setup the NG peer side
> so
> > that it thinks it was setup in sub scenes etc, although it really wasn't,
> > then that would leave prism out of the problem (which makes this an
> easier
> > thing to pull off). hmmm. SubScene itself has a peer. So what I'm
> thinking
> > is, suppose I have a package:
> > >>>>>
> > >>>>> com.sun.javafx.ext.ios.controls
> > >>>>>
> > >>>>> and in this package you have all the skins. There is also someplace
> > in here a map of skin -> sub scene peer, indicating which of the nodes is
> > in which sub scene peer ("layer"). Then when the sync takes place, a skin
> > node looks back at siblings etc to determine if it can be placed in the
> > same layer as something before it. If so, then it sets itself as a child
> on
> > the sub scene as needed. If not, then it creates a new sub scene peer and
> > sets itself on there and then carry on. So then it isn't sync'd to the
> > "real" scene but instead to one of these fake sub scenes that was
> created.
> > >>>>>
> > >>>>> The idea can be refined, but actually I think this approach might
> be
> > workable for doing auto-layering.
> > >>>>>
> > >>>>> Richard
> > >>>>>
> > >>>>> On Oct 22, 2013, at 4:10 PM, Felix Bembrick <
> > felix.bembrick at gmail.com> wrote:
> > >>>>>
> > >>>>>> Yes, having viable implementations of both options would be ideal.
> > >>>>>>
> > >>>>>> How long till Oracle and/or the community gets to that point? ;-)
> > >>>>>>
> > >>>>>>
> > >>>>>> On 23 October 2013 10:06, Stephen F Northover
> > >>>>>> <steve.x.northover at oracle.com>wrote:
> > >>>>>>
> > >>>>>>> Rather than arguing this point, the correct answer is to provide
> > both and
> > >>>>>>> let the application developer choose.
> > >>>>>>>
> > >>>>>>> Do you guys know how old this argument is?  Hint: It predates
> Java.
> > >>>>>>>
> > >>>>>>> Steve
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On 2013-10-22 6:17 PM, Pedro Duque Vieira wrote:
> > >>>>>>>
> > >>>>>>>> Even the most fab skins or CSS is not going to get us away from
> > the need
> > >>>>>>>>> to
> > >>>>>>>>> integrate JavaFX controls with true native controls.  As has
> > been pointed
> > >>>>>>>>> out, there are some native controls on both iOS and Android for
> > which
> > >>>>>>>>> there
> > >>>>>>>>> is no JavaFX equivalent and this will always be the case.  Even
> > if
> > >>>>>>>>> someone
> > >>>>>>>>> were to develop near identical lightweight controls in JavaFX,
> > they would
> > >>>>>>>>> need to behave slightly differently on iOS than they do on
> > Android and
> > >>>>>>>>> vice
> > >>>>>>>>> versa.
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> I don't think this is exactly this straight forward. Ideally you
> > would
> > >>>>>>>> want
> > >>>>>>>> to have this kind of native behavior on every platform. But
> > having this
> > >>>>>>>> native behavior involves having a different version of your app
> > for each
> > >>>>>>>> OS
> > >>>>>>>> you want to deploy in, which might not be what the developers
> > want.
> > >>>>>>>> Remember JavaFX is a cross platform development kit and the
> major
> > reason a
> > >>>>>>>> developer would choose JavaFX over doing native mobile
> > development is that
> > >>>>>>>> his app can run on a variety of mobile platforms: windows 8,
> ipad,
> > >>>>>>>> android,
> > >>>>>>>> iPhone, etc with the same code base and *MOST* importantly with
> > much less
> > >>>>>>>> development time than building an app for each platform.
> > >>>>>>>> For the sake of development time an app that doesn't go against
> > any of the
> > >>>>>>>> different platforms UX but that has the least common denominator
> > so that
> > >>>>>>>> each user in each different platform understands the UI might be
> > a better
> > >>>>>>>> solution for the sake of development time. One such example is
> > the back
> > >>>>>>>> button that appears when you drill down a list on an ios app but
> > doesn't
> > >>>>>>>> appear in an android app because every android phone as a
> > physical back
> > >>>>>>>> button.
> > >>>>>>>>
> > >>>>>>>> I do agree with you that there are some places where a native
> > looking
> > >>>>>>>> control is ideal and doesn't involve any extra effort from the
> > developer
> > >>>>>>>> to
> > >>>>>>>> customize it for the given platform like for instance comboboxs
> > where a
> > >>>>>>>> kind of wheel appears where the user can choose an option, or
> > input
> > >>>>>>>> controls where the native keyboard pops up.
> > >>>>>>>>
> > >>>>>>>> Thanks, best regards,
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>
> > >>
> > >
> >
> >
>



-- 
Sven Reimers

* Senior Expert Software Architect
* NetBeans Dream Team Member: http://dreamteam.netbeans.org
* Community Leader  NetBeans: http://community.java.net/netbeans
                              Desktop Java:
http://community.java.net/javadesktop
* JUG Leader JUG Bodensee: http://www.jug-bodensee.de
* Duke's Choice Award Winner 2009
* Blog: https://www.java.net//blog/sven

* XING: https://www.xing.com/profile/Sven_Reimers8
* LinkedIn: http://www.linkedin.com/in/svenreimers

Join the NetBeans Groups:
* XING: http://www.xing.com/group-20148.82db20
* NUGM: http://haug-server.dyndns.org/display/NUGM/Home
* LinkedIn: http://www.linkedin.com/groups?gid=1860468
                   http://www.linkedin.com/groups?gid=107402
                   http://www.linkedin.com/groups?gid=1684717
* Oracle: https://mix.oracle.com/groups/18497

More information about the openjfx-dev mailing list