Re: JavaFX and iOS - it will remain a dream

[Daniel Zwolenski]

How did you go with using Maven for your iOS stuff Tobi? Did it work out for 
you?

Has anyone else had a chance to get into it? I was hoping for more feedback on 
what works and what doesn't. Also hoping to see some open source demo iOS apps 
popup to start highlighting what works and what doesn't. 

http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/

We all know 'Oracle' has a stupid stance on this, and reading between the lines 
the 'JFX' team are more on our side of the fence but are hamstrung. My personal 
feel is that the only hope is for the community to get the momentum going and 
to use that to then pressure Oracle into doing more. 

I've done what I can on the Maven front, trying to make it easy for developers 
to build apps. It's taken a lot of late nights and burnt up a lot of weekends 
(I even had to go buy a friggen Mac). I've reached my max for investing at this 
stage and need to take a little time to catch up on slipping day job work 
before the next round of fixes and enhancements. 

It would be great to see a real community effort here and see some people take 
up the baton and run the next leg of the relay. Both Niklas and Danno have done 
massive contributions so far too and I don't think they can be expected to 
carry the load alone. 

If you want to help give jfx iOS an actual fighting chance then consider:

- writing some demo apps using the maven stuff, blogging about it, feeding back 
problems and issues so we can start fixing them

- helping Niklas get robovm performant and feature rich (eg build a bundle for 
deployment to the app store)

- talk to Niklas about financially sponsoring his work - if a company or two 
were willing to pay for him to work on it an extra day or two a week I suspect 
we'd see rapid gains

- help maintain the backport run by Danno. Every time there are changes to the 
main jfx code we need to merge these into the backport. This is no small task. 

- help document the Maven plugin and generate usage information including a 
getting started guide and show how to do things like use FXML, change the app 
icon, change plists, run on older versions of ios, etc. 




On 07/08/2013, at 5:19 PM, Tobias Bley  wrote:

> Yes Felix, it *has* to be this year…. We do not port our swing based 
> commercial apps if JavaFX does not run on tablets as well.
> 
> 
> 
> 
> Am 30.07.2013 um 21:06 schrieb Felix Bembrick :
> 
>> Hi Tobi,
>> 
>> I know how you feel.  As much as I am impressed with JavaFX, clearly its 
>> long-term survival does depend on it being viable on mobiles and tablets.
>> 
>> All I can say is don't give up yet.  I am certainly not giving up.  I really 
>> hope we see something at JavaOne this year that will please us all.
>> 
>> It *has* to be this year!
>> 
>> Felix
>> 
>> 
>> 
>> On 31 July 2013 02:40, Tobias Bley  wrote:
>> Hi,
>> 
>> after many days trying to really build iOS apps with JavaFX and RoboVM or 
>> Avian I’m very frustrated because of the following things:
>> 
>> Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know the 
>> reason - maybe it’s the rendering model of JavaFX - maybe it’s the currently 
>> unoptimized RoboVM
>> One big problem of RoboVM is it’s dependence of the Android library, it does 
>> not support the OpenJDK. That’s a big reason for many many problems when 
>> using JavaFX. So currently it’s not possible to use fxml files (FXMLoader) 
>> because of the missing Stax xml parser and classes like XMLInputFactory in 
>> the android library…
>> Avian: we tried to use JavaFX in conjunction with Avian + OpenJDK and AOT 
>> compiling… we hade no success…too complicated build process…no demos 
>> available for iOS…
>> 
>> So in my opinion „JavaFX on iOS“ will remain a dream…If there will be no big 
>> company like Oracle or IBM who actively develops a VM for iOS and Android, 
>> JavaFX will be useless, also on Desktop, then HTML5 or QT will be the big 
>> winner for the most use cases on Desktop and mobile…
>> 
>> Best,
>> Tobi
>> 
>> 
> 

Re: JavaFX and iOS - it will remain a dream

[Tobias Bley]

Yes Felix, it *has* to be this year…. We do not port our swing based commercial 
apps if JavaFX does not run on tablets as well.




Am 30.07.2013 um 21:06 schrieb Felix Bembrick :

> Hi Tobi,
> 
> I know how you feel.  As much as I am impressed with JavaFX, clearly its 
> long-term survival does depend on it being viable on mobiles and tablets.
> 
> All I can say is don't give up yet.  I am certainly not giving up.  I really 
> hope we see something at JavaOne this year that will please us all.
> 
> It *has* to be this year!
> 
> Felix
> 
> 
> 
> On 31 July 2013 02:40, Tobias Bley  wrote:
> Hi,
> 
> after many days trying to really build iOS apps with JavaFX and RoboVM or 
> Avian I’m very frustrated because of the following things:
> 
> Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know the 
> reason - maybe it’s the rendering model of JavaFX - maybe it’s the currently 
> unoptimized RoboVM
> One big problem of RoboVM is it’s dependence of the Android library, it does 
> not support the OpenJDK. That’s a big reason for many many problems when 
> using JavaFX. So currently it’s not possible to use fxml files (FXMLoader) 
> because of the missing Stax xml parser and classes like XMLInputFactory in 
> the android library…
> Avian: we tried to use JavaFX in conjunction with Avian + OpenJDK and AOT 
> compiling… we hade no success…too complicated build process…no demos 
> available for iOS…
> 
> So in my opinion „JavaFX on iOS“ will remain a dream…If there will be no big 
> company like Oracle or IBM who actively develops a VM for iOS and Android, 
> JavaFX will be useless, also on Desktop, then HTML5 or QT will be the big 
> winner for the most use cases on Desktop and mobile…
> 
> Best,
> Tobi
> 
> 

Re: JavaFX and iOS - it will remain a dream

[Tom Schindl]

Hi,

Like advertised I've now the first thing to show off. Part of our
nightly e(fx)clipse build we generate a *self-contained* FXML-Compiler
jar which anyone interested can download from [1].

We currently provide an ant-integration (I'm not 100% happy on how I
make sure the appropriate classpath is chosen) which looks like this:

>   
>   
>   
>   
>classname="org.eclipse.fx.ide.fxml.compiler.ant.FXMLCompilerTask" />
>   
>classpathref="buildpath">
>   
>   
>classpathref="buildpath">
>   

If you want to compile single FXML-Files you can invoke the jar on the
commandline line this:

java -cp org.eclipse.fx.fxml.compiler_0.9.0-SNAPSHOT.jar \
  org.eclipse.fx.ide.fxml.compiler.FXGraphCompiler \
  $fxmlFile \
  $packageRoot

$fxmlFile ... absolute path to your file
$packageRoot ... absolute path to the package-root (to construct the
 package)

so on my localhost I execute it with the like this:

java -cp org.eclipse.fx.fxml.compiler_0.9.0-SNAPSHOT.jar:\
   /tmp/compilersample/test/bin \
   org.eclipse.fx.ide.fxml.compiler.FXGraphCompiler \
   /tmp/compilersample/src/test/Test.fxml \
   /tmp/compilersample/src/

I've also uploaded a sample project to [2].

Tom

[1]
http://download.eclipse.org/efxclipse/compiler-nightly/org.eclipse.fx.fxml.compiler_0.9.0-SNAPSHOT.jar

[2] http://downloads.efxclipse.org/fxml-compiler.zip



On 31.07.13 16:42, Danno Ferrin wrote:
> Where is the code base for this converter?  Done properly it can also be
> written to spit out the generated stubs, as well as output in any
> language the user may prefer.  A top grade implementation could
> integrate with FXMLLoader for a seamless experience ala .bss files.
> 
> On Tuesday, July 30, 2013, Tom Schindl wrote:
> 
> I don't think it is a good idea to use fxml on embedded and mobile,
> we are working on a fxml => java converter so you can add it to your
> build process.
> 
> Tom
> 
> Von meinem iPhone gesendet
> 
> Am 31.07.2013 um 08:11 schrieb Niklas Therning  >:
> 
>  after many days trying to really build iOS apps with JavaFX and
> RoboVM
> >> or
>  Avian I’m very frustrated because of the following things:
> 
>  Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t
> know
> >> the
>  reason - maybe it’s the rendering model of JavaFX - maybe it’s the
>  currently unoptimized RoboVM
>  One big problem of RoboVM is it’s dependence of the Android
> library, it
>  does not support the OpenJDK. That’s a big reason for many many
> >> problems
>  when using JavaFX. So currently it’s not possible to use fxml files
>  (FXMLoader) because of the missing Stax xml parser and classes like
>  XMLInputFactory in the android library…
> >
> > There's now a compatibility library for the jfx78 backport which
> includes
> > the missing sun.* classes from OpenJDK [1]. So that will not be a
> problem
> > when running on RoboVM/Android. Daniel Zwolenski is working on
> getting this
> > into Maven which will make it nice and easy to develop with
> RoboVM+OpenJFX.
> >
> > FXMLLoader relies an StAX and the Java Scripting API. Those can
> both be
> > made to work on RoboVM/Android. The POM of the compat project [1]
> contains
> > optional dependencies on the StAX API and JSR 223 API. For StAX
> you'll also
> > need a StAX provider [2][3]. For scripting you'll need a JSR 223
> > implementation of the scripting language you're using, like Rhino for
> > JavaScript [4][5]. Please note that I haven't tested FXML but it
> should
> > work (in theory at least ;-) ). Please give it a go. It will be a
> great
> > blog story if you can make it work on iOS.
> >
> > As for the performance issues with RoboVM+OpenJFX: those WILL be
> addressed!
> > You can either wait for it to happen or you can help out. One way
> to do
> > that would be sample code that exercises the code paths that need
> to be
> > optimized (e.g. the button rendering you posted about earlier).
> Preferably
> > the sample should run repeatedly without user interaction. You
> should then
> > be able to run Apple's Instruments application to profile this
> sample. This
> > will help us determine what needs to be optimized.
> >
> > /Niklas
> >
> > [1] https://github.com/robovm/robovm-jfx78-compat
> > [2] https://github.com/FasterXML/aalto-xml
> > [3] http://woodstox.codehaus.org/
> > [4] https://developer.mozilla.org/en-US/docs/Rhino
> > [5]
> >
> 
> https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236
> 

Re: JavaFX and iOS - it will remain a dream

[Gaja Sutra]

Depending of security requirements on the deployed code (like in an 
application not loading untrusted code), an hammer method can be useful: 
relaxing access rights on @FXML-annotated fields and methods to allow 
public access.


It would need a preprocessing of application bytecode to change these 
access rights, before compiling FXML and integrating these supplementary 
classes. This can be implemented with a bytecode toolkit like ASM 
(largely used in OpenJDK): http://asm.ow2.org/


Gaja.

The "biggest" problem I have with Controller-Fields and Methods who are
NOT public or package private (depends on the location of the FXML
relative to its controller) because there I still need to use
reflection. Anyone a good idea to get around reflection in case I can't
directly access them?

Re: JavaFX and iOS - it will remain a dream

[Tom Schindl]

Hi,

If you want to take a look at the sources, they are available at
http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/tooling/org.eclipse.fx.ide.fxml.compiler.
Code is written in xtend - don't judge the code yet, I simply want
something going.

The process of the conversion looks like this:

FXML => Internal Memory Model => Java
 ^^
   SaxParser   Converter


So I think your request to have different languages as output is
possible by implementing e.g. a JavaScript converter.

For you second request: Yes there's a helper class named
ExtendedFXMLLoader which you feed a FXML-Path and which at first tries
to load a compiled class and falling back to FXML if not found (see
attached sample).

The "biggest" problem I have with Controller-Fields and Methods who are
NOT public or package private (depends on the location of the FXML
relative to its controller) because there I still need to use
reflection. Anyone a good idea to get around reflection in case I can't
directly access them?

For the initial version I'll simply immediately fallback to reflection
and we could get smarter later on.

I'll expect a first version which supports the most basic stuff to get
out in the next few days. Attached you see my current state. You'll
notice the most basic things already work:
* Simple properties
* Sub-Trees including default properties
* Static properties
* Properties who need to be created through Builders

But naturally there's still a lot left to do ;-)

Tom


On 31.07.13 16:42, Danno Ferrin wrote:
> Where is the code base for this converter?  Done properly it can also be
> written to spit out the generated stubs, as well as output in any
> language the user may prefer.  A top grade implementation could
> integrate with FXMLLoader for a seamless experience ala .bss files.
> 
> On Tuesday, July 30, 2013, Tom Schindl wrote:
> 
> I don't think it is a good idea to use fxml on embedded and mobile,
> we are working on a fxml => java converter so you can add it to your
> build process.
> 
> Tom
> 
> Von meinem iPhone gesendet
> 
> Am 31.07.2013 um 08:11 schrieb Niklas Therning  >:
> 
>  after many days trying to really build iOS apps with JavaFX and
> RoboVM
> >> or
>  Avian I’m very frustrated because of the following things:
> 
>  Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t
> know
> >> the
>  reason - maybe it’s the rendering model of JavaFX - maybe it’s the
>  currently unoptimized RoboVM
>  One big problem of RoboVM is it’s dependence of the Android
> library, it
>  does not support the OpenJDK. That’s a big reason for many many
> >> problems
>  when using JavaFX. So currently it’s not possible to use fxml files
>  (FXMLoader) because of the missing Stax xml parser and classes like
>  XMLInputFactory in the android library…
> >
> > There's now a compatibility library for the jfx78 backport which
> includes
> > the missing sun.* classes from OpenJDK [1]. So that will not be a
> problem
> > when running on RoboVM/Android. Daniel Zwolenski is working on
> getting this
> > into Maven which will make it nice and easy to develop with
> RoboVM+OpenJFX.
> >
> > FXMLLoader relies an StAX and the Java Scripting API. Those can
> both be
> > made to work on RoboVM/Android. The POM of the compat project [1]
> contains
> > optional dependencies on the StAX API and JSR 223 API. For StAX
> you'll also
> > need a StAX provider [2][3]. For scripting you'll need a JSR 223
> > implementation of the scripting language you're using, like Rhino for
> > JavaScript [4][5]. Please note that I haven't tested FXML but it
> should
> > work (in theory at least ;-) ). Please give it a go. It will be a
> great
> > blog story if you can make it work on iOS.
> >
> > As for the performance issues with RoboVM+OpenJFX: those WILL be
> addressed!
> > You can either wait for it to happen or you can help out. One way
> to do
> > that would be sample code that exercises the code paths that need
> to be
> > optimized (e.g. the button rendering you posted about earlier).
> Preferably
> > the sample should run repeatedly without user interaction. You
> should then
> > be able to run Apple's Instruments application to profile this
> sample. This
> > will help us determine what needs to be optimized.
> >
> > /Niklas
> >
> > [1] https://github.com/robovm/robovm-jfx78-compat
> > [2] https://github.com/FasterXML/aalto-xml
> > [3] http://woodstox.codehaus.org/
> > [4] https://developer.mozilla.org/en-US/docs/Rhino
> > [5]
> >
> 
> https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236
> 

package test;

import java.io.IOException;

Re: JavaFX and iOS - it will remain a dream

[Danno Ferrin]

Where is the code base for this converter?  Done properly it can also be
written to spit out the generated stubs, as well as output in any language
the user may prefer.  A top grade implementation could integrate with
FXMLLoader for a seamless experience ala .bss files.

On Tuesday, July 30, 2013, Tom Schindl wrote:

> I don't think it is a good idea to use fxml on embedded and mobile, we are
> working on a fxml => java converter so you can add it to your build process.
>
> Tom
>
> Von meinem iPhone gesendet
>
> Am 31.07.2013 um 08:11 schrieb Niklas Therning 
> 
> >:
>
>  after many days trying to really build iOS apps with JavaFX and RoboVM
> >> or
>  Avian I’m very frustrated because of the following things:
> 
>  Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know
> >> the
>  reason - maybe it’s the rendering model of JavaFX - maybe it’s the
>  currently unoptimized RoboVM
>  One big problem of RoboVM is it’s dependence of the Android library,
> it
>  does not support the OpenJDK. That’s a big reason for many many
> >> problems
>  when using JavaFX. So currently it’s not possible to use fxml files
>  (FXMLoader) because of the missing Stax xml parser and classes like
>  XMLInputFactory in the android library…
> >
> > There's now a compatibility library for the jfx78 backport which includes
> > the missing sun.* classes from OpenJDK [1]. So that will not be a problem
> > when running on RoboVM/Android. Daniel Zwolenski is working on getting
> this
> > into Maven which will make it nice and easy to develop with
> RoboVM+OpenJFX.
> >
> > FXMLLoader relies an StAX and the Java Scripting API. Those can both be
> > made to work on RoboVM/Android. The POM of the compat project [1]
> contains
> > optional dependencies on the StAX API and JSR 223 API. For StAX you'll
> also
> > need a StAX provider [2][3]. For scripting you'll need a JSR 223
> > implementation of the scripting language you're using, like Rhino for
> > JavaScript [4][5]. Please note that I haven't tested FXML but it should
> > work (in theory at least ;-) ). Please give it a go. It will be a great
> > blog story if you can make it work on iOS.
> >
> > As for the performance issues with RoboVM+OpenJFX: those WILL be
> addressed!
> > You can either wait for it to happen or you can help out. One way to do
> > that would be sample code that exercises the code paths that need to be
> > optimized (e.g. the button rendering you posted about earlier).
> Preferably
> > the sample should run repeatedly without user interaction. You should
> then
> > be able to run Apple's Instruments application to profile this sample.
> This
> > will help us determine what needs to be optimized.
> >
> > /Niklas
> >
> > [1] https://github.com/robovm/robovm-jfx78-compat
> > [2] https://github.com/FasterXML/aalto-xml
> > [3] http://woodstox.codehaus.org/
> > [4] https://developer.mozilla.org/en-US/docs/Rhino
> > [5]
> >
> https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236
>

Re: JavaFX and iOS - it will remain a dream

[Gaja Sutra]

Have you decided, how you will make the bridge near the current 
FXMLLoader class. Particularly, will it be understandable by Proguard 
for better inlining and further reduce bytecode?


Example: if a specific FXML is only loaded in one method of an 
application, all the FXMLLoader code can theoretically be replaced 
directly by the generated Java code building the object as defined by 
FXML, but without any indirection layer.


Thanks,
Gaja.


I don't think it is a good idea to use fxml on embedded and mobile, we are working 
on a fxml => java converter so you can add it to your build process.

Tom

Re: JavaFX and iOS - it will remain a dream

[Tom Schindl]

It will spit out a .java-Class which you run through javac and get
bytecode - for robovm this is going to be completely transparent because
it gets a java-class file.

Tom

On 31.07.13 09:57, Niklas Therning wrote:
> Will this converter be able to precompile embedded JavaScript? That
> would be very cool. If I remember correctly Rhino can compile JS to
> bytecode AOT. RoboVM would then be able to compile that bytecode to
> machine code.
> 
> 
> On Wed, Jul 31, 2013 at 8:28 AM, Tom Schindl
> mailto:tom.schi...@bestsolution.at>> wrote:
> 
> I don't think it is a good idea to use fxml on embedded and mobile,
> we are working on a fxml => java converter so you can add it to your
> build process.
> 
> Tom
> 
> Von meinem iPhone gesendet
> 
> Am 31.07.2013 um 08:11 schrieb Niklas Therning  >:
> 
>  after many days trying to really build iOS apps with JavaFX and
> RoboVM
> >> or
>  Avian I’m very frustrated because of the following things:
> 
>  Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t
> know
> >> the
>  reason - maybe it’s the rendering model of JavaFX - maybe it’s the
>  currently unoptimized RoboVM
>  One big problem of RoboVM is it’s dependence of the Android
> library, it
>  does not support the OpenJDK. That’s a big reason for many many
> >> problems
>  when using JavaFX. So currently it’s not possible to use fxml files
>  (FXMLoader) because of the missing Stax xml parser and classes like
>  XMLInputFactory in the android library…
> >
> > There's now a compatibility library for the jfx78 backport which
> includes
> > the missing sun.* classes from OpenJDK [1]. So that will not be a
> problem
> > when running on RoboVM/Android. Daniel Zwolenski is working on
> getting this
> > into Maven which will make it nice and easy to develop with
> RoboVM+OpenJFX.
> >
> > FXMLLoader relies an StAX and the Java Scripting API. Those can
> both be
> > made to work on RoboVM/Android. The POM of the compat project [1]
> contains
> > optional dependencies on the StAX API and JSR 223 API. For StAX
> you'll also
> > need a StAX provider [2][3]. For scripting you'll need a JSR 223
> > implementation of the scripting language you're using, like Rhino for
> > JavaScript [4][5]. Please note that I haven't tested FXML but it
> should
> > work (in theory at least ;-) ). Please give it a go. It will be a
> great
> > blog story if you can make it work on iOS.
> >
> > As for the performance issues with RoboVM+OpenJFX: those WILL be
> addressed!
> > You can either wait for it to happen or you can help out. One way
> to do
> > that would be sample code that exercises the code paths that need
> to be
> > optimized (e.g. the button rendering you posted about earlier).
> Preferably
> > the sample should run repeatedly without user interaction. You
> should then
> > be able to run Apple's Instruments application to profile this
> sample. This
> > will help us determine what needs to be optimized.
> >
> > /Niklas
> >
> > [1] https://github.com/robovm/robovm-jfx78-compat
> > [2] https://github.com/FasterXML/aalto-xml
> > [3] http://woodstox.codehaus.org/
> > [4] https://developer.mozilla.org/en-US/docs/Rhino
> > [5]
> >
> 
> https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236
> 
> 

Re: JavaFX and iOS - it will remain a dream

[Tom Schindl]

On constrainted devices it is simply too slow because of all the
reflection happening, you need to look up classes, decide on what a
property means, doing type conversions from String to int, bool, ...
this all eats up CPU-time!

Tom

On 31.07.13 09:15, John C. Turnbull wrote:
> Tom, why do you think FXML on mobiles is a bad idea?  Performance?
> 
> -Original Message-
> From: openjfx-dev-boun...@openjdk.java.net 
> [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Tom Schindl
> Sent: Wednesday, 31 July 2013 16:29
> To: Niklas Therning
> Cc: openjfx-dev@openjdk.java.net Mailing
> Subject: Re: JavaFX and iOS - it will remain a dream
> 
> I don't think it is a good idea to use fxml on embedded and mobile, we are 
> working on a fxml => java converter so you can add it to your build process.
> 
> Tom
> 
> Von meinem iPhone gesendet
> 
> Am 31.07.2013 um 08:11 schrieb Niklas Therning :
> 
>>>>> after many days trying to really build iOS apps with JavaFX and 
>>>>> RoboVM
>>> or
>>>>> Avian I’m very frustrated because of the following things:
>>>>>
>>>>> Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t 
>>>>> know
>>> the
>>>>> reason - maybe it’s the rendering model of JavaFX - maybe it’s the 
>>>>> currently unoptimized RoboVM One big problem of RoboVM is it’s 
>>>>> dependence of the Android library, it does not support the OpenJDK. 
>>>>> That’s a big reason for many many
>>> problems
>>>>> when using JavaFX. So currently it’s not possible to use fxml files
>>>>> (FXMLoader) because of the missing Stax xml parser and classes like 
>>>>> XMLInputFactory in the android library…
>>
>> There's now a compatibility library for the jfx78 backport which 
>> includes the missing sun.* classes from OpenJDK [1]. So that will not 
>> be a problem when running on RoboVM/Android. Daniel Zwolenski is 
>> working on getting this into Maven which will make it nice and easy to 
>> develop with RoboVM+OpenJFX.
>>
>> FXMLLoader relies an StAX and the Java Scripting API. Those can both 
>> be made to work on RoboVM/Android. The POM of the compat project [1] 
>> contains optional dependencies on the StAX API and JSR 223 API. For 
>> StAX you'll also need a StAX provider [2][3]. For scripting you'll 
>> need a JSR 223 implementation of the scripting language you're using, 
>> like Rhino for JavaScript [4][5]. Please note that I haven't tested 
>> FXML but it should work (in theory at least ;-) ). Please give it a 
>> go. It will be a great blog story if you can make it work on iOS.
>>
>> As for the performance issues with RoboVM+OpenJFX: those WILL be addressed!
>> You can either wait for it to happen or you can help out. One way to 
>> do that would be sample code that exercises the code paths that need 
>> to be optimized (e.g. the button rendering you posted about earlier). 
>> Preferably the sample should run repeatedly without user interaction. 
>> You should then be able to run Apple's Instruments application to 
>> profile this sample. This will help us determine what needs to be optimized.
>>
>> /Niklas
>>
>> [1] https://github.com/robovm/robovm-jfx78-compat
>> [2] https://github.com/FasterXML/aalto-xml
>> [3] http://woodstox.codehaus.org/
>> [4] https://developer.mozilla.org/en-US/docs/Rhino
>> [5]
>> https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236
> 

Re: JavaFX and iOS - it will remain a dream

[Niklas Therning]

Will this converter be able to precompile embedded JavaScript? That would
be very cool. If I remember correctly Rhino can compile JS to bytecode AOT.
RoboVM would then be able to compile that bytecode to machine code.


On Wed, Jul 31, 2013 at 8:28 AM, Tom Schindl wrote:

> I don't think it is a good idea to use fxml on embedded and mobile, we are
> working on a fxml => java converter so you can add it to your build process.
>
> Tom
>
> Von meinem iPhone gesendet
>
> Am 31.07.2013 um 08:11 schrieb Niklas Therning :
>
>  after many days trying to really build iOS apps with JavaFX and RoboVM
> >> or
>  Avian I’m very frustrated because of the following things:
> 
>  Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know
> >> the
>  reason - maybe it’s the rendering model of JavaFX - maybe it’s the
>  currently unoptimized RoboVM
>  One big problem of RoboVM is it’s dependence of the Android library,
> it
>  does not support the OpenJDK. That’s a big reason for many many
> >> problems
>  when using JavaFX. So currently it’s not possible to use fxml files
>  (FXMLoader) because of the missing Stax xml parser and classes like
>  XMLInputFactory in the android library…
> >
> > There's now a compatibility library for the jfx78 backport which includes
> > the missing sun.* classes from OpenJDK [1]. So that will not be a problem
> > when running on RoboVM/Android. Daniel Zwolenski is working on getting
> this
> > into Maven which will make it nice and easy to develop with
> RoboVM+OpenJFX.
> >
> > FXMLLoader relies an StAX and the Java Scripting API. Those can both be
> > made to work on RoboVM/Android. The POM of the compat project [1]
> contains
> > optional dependencies on the StAX API and JSR 223 API. For StAX you'll
> also
> > need a StAX provider [2][3]. For scripting you'll need a JSR 223
> > implementation of the scripting language you're using, like Rhino for
> > JavaScript [4][5]. Please note that I haven't tested FXML but it should
> > work (in theory at least ;-) ). Please give it a go. It will be a great
> > blog story if you can make it work on iOS.
> >
> > As for the performance issues with RoboVM+OpenJFX: those WILL be
> addressed!
> > You can either wait for it to happen or you can help out. One way to do
> > that would be sample code that exercises the code paths that need to be
> > optimized (e.g. the button rendering you posted about earlier).
> Preferably
> > the sample should run repeatedly without user interaction. You should
> then
> > be able to run Apple's Instruments application to profile this sample.
> This
> > will help us determine what needs to be optimized.
> >
> > /Niklas
> >
> > [1] https://github.com/robovm/robovm-jfx78-compat
> > [2] https://github.com/FasterXML/aalto-xml
> > [3] http://woodstox.codehaus.org/
> > [4] https://developer.mozilla.org/en-US/docs/Rhino
> > [5]
> >
> https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236
>

Re: JavaFX and iOS - it will remain a dream

[Tom Eugelink]

Not answering for my fellow Tom but for myself; FXML is a format that is mainly of 
interest to the developer, not the runtime environment. So, like precompiled JSP, there 
is something to say for "compiling" something that is actually programming 
code, no matter in which context it is used.

On 2013-07-31 09:15, John C. Turnbull wrote:

Tom, why do you think FXML on mobiles is a bad idea?  Performance?

-Original Message-
From: openjfx-dev-boun...@openjdk.java.net 
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Tom Schindl
Sent: Wednesday, 31 July 2013 16:29
To: Niklas Therning
Cc: openjfx-dev@openjdk.java.net Mailing
Subject: Re: JavaFX and iOS - it will remain a dream

I don't think it is a good idea to use fxml on embedded and mobile, we are working 
on a fxml => java converter so you can add it to your build process.

Tom

Von meinem iPhone gesendet

Am 31.07.2013 um 08:11 schrieb Niklas Therning :


after many days trying to really build iOS apps with JavaFX and
RoboVM

or

Avian I’m very frustrated because of the following things:

Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t
know

the

reason - maybe it’s the rendering model of JavaFX - maybe it’s the
currently unoptimized RoboVM One big problem of RoboVM is it’s
dependence of the Android library, it does not support the OpenJDK.
That’s a big reason for many many

problems

when using JavaFX. So currently it’s not possible to use fxml files
(FXMLoader) because of the missing Stax xml parser and classes like
XMLInputFactory in the android library…

There's now a compatibility library for the jfx78 backport which
includes the missing sun.* classes from OpenJDK [1]. So that will not
be a problem when running on RoboVM/Android. Daniel Zwolenski is
working on getting this into Maven which will make it nice and easy to develop 
with RoboVM+OpenJFX.

FXMLLoader relies an StAX and the Java Scripting API. Those can both
be made to work on RoboVM/Android. The POM of the compat project [1]
contains optional dependencies on the StAX API and JSR 223 API. For
StAX you'll also need a StAX provider [2][3]. For scripting you'll
need a JSR 223 implementation of the scripting language you're using,
like Rhino for JavaScript [4][5]. Please note that I haven't tested
FXML but it should work (in theory at least ;-) ). Please give it a
go. It will be a great blog story if you can make it work on iOS.

As for the performance issues with RoboVM+OpenJFX: those WILL be addressed!
You can either wait for it to happen or you can help out. One way to
do that would be sample code that exercises the code paths that need
to be optimized (e.g. the button rendering you posted about earlier).
Preferably the sample should run repeatedly without user interaction.
You should then be able to run Apple's Instruments application to
profile this sample. This will help us determine what needs to be optimized.

/Niklas

[1] https://github.com/robovm/robovm-jfx78-compat
[2] https://github.com/FasterXML/aalto-xml
[3] http://woodstox.codehaus.org/
[4] https://developer.mozilla.org/en-US/docs/Rhino
[5]
https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236

RE: JavaFX and iOS - it will remain a dream

[John C. Turnbull]

Tom, why do you think FXML on mobiles is a bad idea?  Performance?

-Original Message-
From: openjfx-dev-boun...@openjdk.java.net 
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Tom Schindl
Sent: Wednesday, 31 July 2013 16:29
To: Niklas Therning
Cc: openjfx-dev@openjdk.java.net Mailing
Subject: Re: JavaFX and iOS - it will remain a dream

I don't think it is a good idea to use fxml on embedded and mobile, we are 
working on a fxml => java converter so you can add it to your build process.

Tom

Von meinem iPhone gesendet

Am 31.07.2013 um 08:11 schrieb Niklas Therning :

>>>> after many days trying to really build iOS apps with JavaFX and 
>>>> RoboVM
>> or
>>>> Avian I’m very frustrated because of the following things:
>>>> 
>>>> Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t 
>>>> know
>> the
>>>> reason - maybe it’s the rendering model of JavaFX - maybe it’s the 
>>>> currently unoptimized RoboVM One big problem of RoboVM is it’s 
>>>> dependence of the Android library, it does not support the OpenJDK. 
>>>> That’s a big reason for many many
>> problems
>>>> when using JavaFX. So currently it’s not possible to use fxml files
>>>> (FXMLoader) because of the missing Stax xml parser and classes like 
>>>> XMLInputFactory in the android library…
> 
> There's now a compatibility library for the jfx78 backport which 
> includes the missing sun.* classes from OpenJDK [1]. So that will not 
> be a problem when running on RoboVM/Android. Daniel Zwolenski is 
> working on getting this into Maven which will make it nice and easy to 
> develop with RoboVM+OpenJFX.
> 
> FXMLLoader relies an StAX and the Java Scripting API. Those can both 
> be made to work on RoboVM/Android. The POM of the compat project [1] 
> contains optional dependencies on the StAX API and JSR 223 API. For 
> StAX you'll also need a StAX provider [2][3]. For scripting you'll 
> need a JSR 223 implementation of the scripting language you're using, 
> like Rhino for JavaScript [4][5]. Please note that I haven't tested 
> FXML but it should work (in theory at least ;-) ). Please give it a 
> go. It will be a great blog story if you can make it work on iOS.
> 
> As for the performance issues with RoboVM+OpenJFX: those WILL be addressed!
> You can either wait for it to happen or you can help out. One way to 
> do that would be sample code that exercises the code paths that need 
> to be optimized (e.g. the button rendering you posted about earlier). 
> Preferably the sample should run repeatedly without user interaction. 
> You should then be able to run Apple's Instruments application to 
> profile this sample. This will help us determine what needs to be optimized.
> 
> /Niklas
> 
> [1] https://github.com/robovm/robovm-jfx78-compat
> [2] https://github.com/FasterXML/aalto-xml
> [3] http://woodstox.codehaus.org/
> [4] https://developer.mozilla.org/en-US/docs/Rhino
> [5]
> https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236

Re: JavaFX and iOS - it will remain a dream

[Tom Schindl]

I don't think it is a good idea to use fxml on embedded and mobile, we are 
working on a fxml => java converter so you can add it to your build process.

Tom

Von meinem iPhone gesendet

Am 31.07.2013 um 08:11 schrieb Niklas Therning :

 after many days trying to really build iOS apps with JavaFX and RoboVM
>> or
 Avian I’m very frustrated because of the following things:
 
 Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know
>> the
 reason - maybe it’s the rendering model of JavaFX - maybe it’s the
 currently unoptimized RoboVM
 One big problem of RoboVM is it’s dependence of the Android library, it
 does not support the OpenJDK. That’s a big reason for many many
>> problems
 when using JavaFX. So currently it’s not possible to use fxml files
 (FXMLoader) because of the missing Stax xml parser and classes like
 XMLInputFactory in the android library…
> 
> There's now a compatibility library for the jfx78 backport which includes
> the missing sun.* classes from OpenJDK [1]. So that will not be a problem
> when running on RoboVM/Android. Daniel Zwolenski is working on getting this
> into Maven which will make it nice and easy to develop with RoboVM+OpenJFX.
> 
> FXMLLoader relies an StAX and the Java Scripting API. Those can both be
> made to work on RoboVM/Android. The POM of the compat project [1] contains
> optional dependencies on the StAX API and JSR 223 API. For StAX you'll also
> need a StAX provider [2][3]. For scripting you'll need a JSR 223
> implementation of the scripting language you're using, like Rhino for
> JavaScript [4][5]. Please note that I haven't tested FXML but it should
> work (in theory at least ;-) ). Please give it a go. It will be a great
> blog story if you can make it work on iOS.
> 
> As for the performance issues with RoboVM+OpenJFX: those WILL be addressed!
> You can either wait for it to happen or you can help out. One way to do
> that would be sample code that exercises the code paths that need to be
> optimized (e.g. the button rendering you posted about earlier). Preferably
> the sample should run repeatedly without user interaction. You should then
> be able to run Apple's Instruments application to profile this sample. This
> will help us determine what needs to be optimized.
> 
> /Niklas
> 
> [1] https://github.com/robovm/robovm-jfx78-compat
> [2] https://github.com/FasterXML/aalto-xml
> [3] http://woodstox.codehaus.org/
> [4] https://developer.mozilla.org/en-US/docs/Rhino
> [5]
> https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236

Re: JavaFX and iOS - it will remain a dream

[Niklas Therning]

> > > after many days trying to really build iOS apps with JavaFX and RoboVM
> or
> > > Avian I’m very frustrated because of the following things:
> > >
> > > Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know
> the
> > > reason - maybe it’s the rendering model of JavaFX - maybe it’s the
> > > currently unoptimized RoboVM
> > > One big problem of RoboVM is it’s dependence of the Android library, it
> > > does not support the OpenJDK. That’s a big reason for many many
> problems
> > > when using JavaFX. So currently it’s not possible to use fxml files
> > > (FXMLoader) because of the missing Stax xml parser and classes like
> > > XMLInputFactory in the android library…
>

There's now a compatibility library for the jfx78 backport which includes
the missing sun.* classes from OpenJDK [1]. So that will not be a problem
when running on RoboVM/Android. Daniel Zwolenski is working on getting this
into Maven which will make it nice and easy to develop with RoboVM+OpenJFX.

FXMLLoader relies an StAX and the Java Scripting API. Those can both be
made to work on RoboVM/Android. The POM of the compat project [1] contains
optional dependencies on the StAX API and JSR 223 API. For StAX you'll also
need a StAX provider [2][3]. For scripting you'll need a JSR 223
implementation of the scripting language you're using, like Rhino for
JavaScript [4][5]. Please note that I haven't tested FXML but it should
work (in theory at least ;-) ). Please give it a go. It will be a great
blog story if you can make it work on iOS.

As for the performance issues with RoboVM+OpenJFX: those WILL be addressed!
You can either wait for it to happen or you can help out. One way to do
that would be sample code that exercises the code paths that need to be
optimized (e.g. the button rendering you posted about earlier). Preferably
the sample should run repeatedly without user interaction. You should then
be able to run Apple's Instruments application to profile this sample. This
will help us determine what needs to be optimized.

/Niklas

[1] https://github.com/robovm/robovm-jfx78-compat
[2] https://github.com/FasterXML/aalto-xml
[3] http://woodstox.codehaus.org/
[4] https://developer.mozilla.org/en-US/docs/Rhino
[5]
https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236

Re: JavaFX and iOS - it will remain a dream

[Rick Walker]

I agree, our customers want and need tablet/mobile solutions to complement
our desktop offering. The current "give it a shot, good luck, let us know
how it goes" approach is not the way to advance JavaFX in the mobile space.

Rick


On Tue, Jul 30, 2013 at 3:06 PM, Felix Bembrick wrote:

> Hi Tobi,
>
> I know how you feel.  As much as I am impressed with JavaFX, clearly its
> long-term survival does depend on it being viable on mobiles and tablets.
>
> All I can say is don't give up yet.  I am certainly not giving up.  I
> really hope we see something at JavaOne this year that will please us all.
>
> It *has* to be this year!
>
> Felix
>
>
>
> On 31 July 2013 02:40, Tobias Bley  wrote:
>
> > Hi,
> >
> > after many days trying to really build iOS apps with JavaFX and RoboVM or
> > Avian I’m very frustrated because of the following things:
> >
> > Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know the
> > reason - maybe it’s the rendering model of JavaFX - maybe it’s the
> > currently unoptimized RoboVM
> > One big problem of RoboVM is it’s dependence of the Android library, it
> > does not support the OpenJDK. That’s a big reason for many many problems
> > when using JavaFX. So currently it’s not possible to use fxml files
> > (FXMLoader) because of the missing Stax xml parser and classes like
> > XMLInputFactory in the android library…
> > Avian: we tried to use JavaFX in conjunction with Avian + OpenJDK and AOT
> > compiling… we hade no success…too complicated build process…no demos
> > available for iOS…
> >
> > So in my opinion „JavaFX on iOS“ will remain a dream…If there will be no
> > big company like Oracle or IBM who actively develops a VM for iOS and
> > Android, JavaFX will be useless, also on Desktop, then HTML5 or QT will
> be
> > the big winner for the most use cases on Desktop and mobile…
> >
> > Best,
> > Tobi
> >
> >
>



-- 
Richard P. Walker
thoughtslin...@gmail.com

This email is intended only for the use of the individual(s) to whom it is
addressed and may be privileged and confidential. Unauthorised use or
disclosure is prohibited. If you receive this e-mail in error, please
advise immediately and delete the original message. This message may have
been altered without your or our knowledge and the sender does not accept
any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux
droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou
copie de ce message ou des renseignements qu'il contient par une personne
autre que le (les) destinataire(s) désigné(s) est interdite. Si vous
recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par
retour de courriel ou par un autre moyen.

Re: JavaFX and iOS - it will remain a dream

[Felix Bembrick]

Hi Tobi,

I know how you feel.  As much as I am impressed with JavaFX, clearly its
long-term survival does depend on it being viable on mobiles and tablets.

All I can say is don't give up yet.  I am certainly not giving up.  I
really hope we see something at JavaOne this year that will please us all.

It *has* to be this year!

Felix



On 31 July 2013 02:40, Tobias Bley  wrote:

> Hi,
>
> after many days trying to really build iOS apps with JavaFX and RoboVM or
> Avian I’m very frustrated because of the following things:
>
> Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know the
> reason - maybe it’s the rendering model of JavaFX - maybe it’s the
> currently unoptimized RoboVM
> One big problem of RoboVM is it’s dependence of the Android library, it
> does not support the OpenJDK. That’s a big reason for many many problems
> when using JavaFX. So currently it’s not possible to use fxml files
> (FXMLoader) because of the missing Stax xml parser and classes like
> XMLInputFactory in the android library…
> Avian: we tried to use JavaFX in conjunction with Avian + OpenJDK and AOT
> compiling… we hade no success…too complicated build process…no demos
> available for iOS…
>
> So in my opinion „JavaFX on iOS“ will remain a dream…If there will be no
> big company like Oracle or IBM who actively develops a VM for iOS and
> Android, JavaFX will be useless, also on Desktop, then HTML5 or QT will be
> the big winner for the most use cases on Desktop and mobile…
>
> Best,
> Tobi
>
>