Probably a mix of a couple of things. Mostly AOT with interpreting where necessary. No JIT possible on iOS.
On 24 October 2013 22:27, Sven Reimers <[email protected]> wrote: > So in case of VM - what are we talking about? > > a) Running a real JVM with JIT all the good stuff on iOS? (I can't see > this happening for official appstore apps) > b) Adding a possibility to OpenJDK to get AOT? > > What is the aim? > > -Sven > > > > On Thu, Oct 24, 2013 at 11:29 AM, Felix Bembrick <[email protected] > > wrote: > >> Much of what you are saying Tobi is absolutely true. >> >> I have always said that it's simply not enough to have experimental or >> "alpha" or "hobbyist" implementations of Java and JavaFX on those >> platforms. As I have stated in my blogs, we need a thoroughly >> professional >> solution that is suitable for *serious commercial app development*. >> >> Anything less is a fail. That was the motivation for my "6 Degrees" >> post. >> Even if one of those points is not satisfied then the port is not viable. >> >> However, I disagree with your assertion that Oracle (or any big company) >> needs to release the JVM and supporting classes/libraries themselves. >> While obviously this would be ideal, if we (the community) want this to >> happen in a reasonable time frame then *we* have to make it happen or at >> >> least contribute a lot of time and effort in support of making it happen. >> >> To this end, we already have RoboVM. As you have pointed out, RoboVM is >> not "production ready" just yet and may indeed be a long way off that but >> have you ever heard the saying "A bird in the hand is worth two in the >> bush"? >> >> Basically, RoboVM is here and now and, at least in part, seems to work >> quite well. Sure, it needs to be modified to remove the Dalvik library >> dependencies and to support JDK8 but I have strong feeling that it's all >> we >> are going to have for quite a long time and we might as well put the >> effort >> into improving it. >> >> So, my own feeling is that the JavaFX community is very vibrant and there >> are a lot of cluey people out there and collectively we have the ability >> to >> make RoboVM viable (6 Degrees wise). >> >> We do not need to wait for Oracle and we shouldn't. In fact, I am sure >> that Oracle themselves (whatever they are actually working on) are taking >> a >> very close look at RoboVM and possibly getting hints and pointers from it. >> It's no secret that JavaFX (and even Java) is not the most important >> technology or product in Oracle's catalogue and I am sure the JavaFX team >> is under-funded. >> >> So why can't we the community and Oracle work together to make this >> happen? >> Maybe it would be better to pool our resources and focus all our energy >> on >> a single unified solution? >> >> Of course we would need Oracle to be a bit more cooperative and open but >> who says that won't happen? >> >> So basically I think the wonderful initiative that is RoboVM and the work >> on it is not at all wasted and indeed will be a very valuable step toward >> the ultimate goal. >> >> Felix >> >> >> >> >> On 24 October 2013 17:52, Tobias Bley <[email protected]> wrote: >> >> > ups, I made one mistake: >> > >> > "So both solutions use the real Java platform (=OpenJDK)!“ should be "So >> > both solutions does not use the real Java platform (=OpenJDK)!“ ;) >> > >> > >> > Am 24.10.2013 um 08:41 schrieb Tobias Bley <[email protected]>: >> > >> > > 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 <[email protected] >> >: >> > > >> > >> Yes, definitely. >> > >> >> > >>> On Oct 23, 2013, at 11:52 AM, Scott Palmer <[email protected]> >> 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 < >> > [email protected]> 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 < >> [email protected]> >> > 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 >> > >>>>> <[email protected]>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 > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * 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 >
