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 <fbrun...@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.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,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>
>
