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 <felix.bembr...@gmail.com>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 <t...@ultramixer.com> 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 <t...@ultramixer.com>: > > > > > 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.b...@oracle.com>: > > > > > >> Yes, definitely. > > >> > > >>> On Oct 23, 2013, at 11:52 AM, Scott Palmer <swpal...@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.b...@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.bembr...@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.northo...@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 * 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