I thought those JVM's were considered to be steps in progression toward
production JVM's? Though the "push" was toward full utility, I thought the
wagon train would circle back around to do "optimization passes" and so
forth? Remember we started from absolutely nothing and a question as to its
possibility? Now we know conclusively that it's possible - and I thought
the work could be extended upon?
If Oracle is to be the true "steward" of Java, I think they need to do more
than what I call "Gesturing". If one intends to end hunger in Africa, you
get on a plane and go there and physically work on the problem until it's
solved, not put your (albeit grand "gesture") of 1 million dollars in the
collection plate and forget about it. Of course, it's easy for people like
me to sit back and judge - but I didn't go and purchase Sun and announce to
the world my stewardship of one of the most important technologies in
existence. Either do it all the way or stay the &*&*&^ out of the way - as
far as I'm concerned.
Of course this is not to condemn the heroic efforts of people here who live
and breathe their contribution to Java. I just think a partial commitment
(no matter how grand), is in the end detrimental. Sorry...
On Thu, Oct 24, 2013 at 1:41 AM, Tobias Bley <t...@ultramixer.com> wrote:
> 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,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>
>
>
