Hi Tom,
although emulator supports opengl it doesn't have required opengl extension.

On 01/09/2014 05:10 PM, Tom Schindl wrote:
Have you managed to get an JavaFX running on the emulator. I've tested
with one of ours and while it works great on the real device. It crashes
in the emulator.

V/GLASS   ( 1121): JNI call notifyViewEvent to lensView 0x1d30041a
W/System.err( 1121): java.lang.UnsupportedOperationException: Pixel format 
BYTE_BGRA_PRE not supported on this device
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at 
W/System.err( 1121):    at java.lang.Thread.run(Thread.java:841)
I have to say that I've never seen a crapier thing than this emulator.
Could we produce x86 binaries so that we can use genymotion?


On 09.01.14 11:05, Johan Vos wrote:
Hi Steve,

Doing this step by step, we probably need a solution on the use of JDK 8
language features first. As you mentioned in
https://javafx-jira.kenai.com/browse/RT-35165, there is probably
(unfortunately) no real option apart from having different source
directories. How do we tackle this?
I think we only need to have the affected files in a different directory,
but then we need a build mechanism that use the alternate directory first
in the Android(/iOS?) case. How can this be done without polluting the
build system? Also, we need to make sure that general changes in affected
files are also changed in the alternate directory.
It seems we somehow need a fork of the javafx source files, do the
modifications, and merge changes from the upstream into the fork whenever
changes occur. This is how we currently do it on bitbucket, but I don't
think that is an option here?

Apart from this building issue, I agree that we need to have a solution for
the Java 8 features. Retrolambda probably fixes the lambda
incompatibilities (haven't used it yet, but at least from a theoretical
point, it should be possible to use this). The default interfaces is more
tricky, but we'll have to come up with a solution for this as well.

- Johan

2014/1/2 Stephen F Northover <steve.x.northo...@oracle.com>

  Hi Johan,

I looked and the kinds of changes that you are making in
https://bitbucket.org/javafxports/android-graphics-rt and I can see that
they fall into a number of different categories:

1) JDK8 Language Features

- work arounds for ObservableList default methods
- work arounds for the use of lambda (in test and example code)
- work arounds for the lack of final declarations (in test and example

I have entered https://javafx-jira.kenai.com/browse/RT-35165 to track the
defender method problem.

Eventually, OpenJFX will embrace lambda expressions and it is likely that
iOS and Android will need to use RetroLambda.  When we embrace lambda,
there will be a JIRA that covers the work and you an watch progress there.
In the meantime, you could look into RetroLambda now and see if it will
help you.  Since it works on byte codes, you won't be able to step in the
debugger because the source won't match the executable.  This might not be
an issue for you.  ASIDE: I've attempted to build the code under Android
Studio and it runs out of method handles in dex during compile.  Any ideas?

In the case of final declarations, I think that there are so few of them
right now that we can just fix them as then sneak in.  You will need to
keep track of them as they happen.  Eventually, if you earn commit rights,
you can just fix them.

2) JDK8 Library (modules/compat/src)

- missing classes and annotations (such as FunctionalInterface)
- missing API in JDK7 classes (I thought I had gotten rid of these)

This code is not part of OpenJFX and should not be in the repo.  Instead,
you need to maintain and build the code somewhere else and make a jar
available as part of your build.  For example, when OpenJFX is built, it
gets the SWT jar from Eclipse.org.  You will need to do something similar
when OpenJFX for Android or iOS is built.

3) Android Build Files and Tools (android-tools and more)

- files like dalvik.gradle and shell scripts etc.

Some of this is being tracked by
https://javafx-jira.kenai.com/browse/RT-35123 .  I suggest that you enter
JIRA for each part that you want moved over.  For example, android-tools is
not covered by this JIRA.

4) Android Specific Files (New and Changed files)

- src/dalvik
- android.h, LensApplication.c etc.

You will need to enter JIRA for these.  I'm not sure which changes are
needed and which are not.  FX embedded committers will need to go over the
changes as Android and Lens share the same code.

5) "Unnecessary Changes"

- these are mostly due to being out of sync with OpenJFX
- some of these are related to FunctionalInterface which you should add to
your JDK8 compat library

As more of your code moves over to OpenJFX, the list of changes here will
become zero.  I suggest that you browse all the changes that you have and
get rid of as many as you can while preparing patches for OpenJFX.

Best of luck Johan!  Our goal is to bootstrap you port as quickly as we
can subject to the rules of the OpenJDK which we must follow.  Please enter
JIRA as necessary to track your work and we can interact there.

Happy New Year!


On 2013-12-31 3:47 AM, Johan Vos wrote:


  The main issue is currently getting bootstrapped. If we want to build the
Dalvik-runtime using open-jfx, we need a location on where to put the
dalvik files. This is what I tried to describe in

  Please note that we're not really doing an Android port, but a Dalvik
port. The (excellent) work done by Oracle in the past allowed for both
using Dalvik as well as an Oracle-internal VM. There are no indications
that the latter is ever going to fly, so I don't want to have an
abstraction on top of {Dalvik, OracleVM} if only the first one exists. I do
hope there will be other VM's (Oracle VM and more) later, as that will make
it easier to have Java 8 and so on, but right now we have to stick with
what we have (dalvik).

  Without these files, we can supply patches for existing files in
open-jfx, but by no means we can build the runtime. I do understand it is
not trivial to "add" a directory for the sake of a port, but then, a port
is not trivial as well. I'm open to all suggestions.
The longer we wait, however, with synchronizing the bitbucket repo with
the open-jfx repo, the harder it gets. Right now, I have no other option
than committing all changes in the bitbucket repo, as I need to be able to
build a runtime. We had 419 downloads of the runtime in 10 days, so clearly
there are people interested in this.

  - Johan

2013/12/20 Stephen F Northover <steve.x.northo...@oracle.com>

Hi Johan,

This is very good news.  We need to work together so that you are able to
run OpenJFX unmodified.  This may not be practical for all sorts of
reasons, but we need to seriously explore this and work towards this goal.
  Please open JIRA for the various problems you are seeing and we can try to
deal with them there and on this list.


On 2013-12-20 12:56 PM, Johan Vos wrote:


As you might know, 2 months ago I started a community effort for
JavaFX to Android. Today, we released build 3 of the JavaFX Android
runtime, which can be downloaded at
instructions on how to build applications at


Building the runtime itself is explained at


At this moment, most of the Ensemble suite runs on Android (positive
reports starting with Android 3.x).

The downloadable runtime is created using the bitbucket project at
https://bitbucket.org/javafxports/android-graphics-rt which is a fork of
the openjfx-graphics-rt mirror on bitbucket. We merge often, so all
made in openjfx-graphics should be in the Android runtime as well.

There are a number of issues left:
* touch map issues causing applications to crash if "touched too much". I
created a JIRA ticket for this and will create another one (related, but
not same cause) later.
* Java 7 only. Currently, applications cannot make use of Java 8
Dalvik has no invokedynamic, so we can't do lambda's.
* we just started, so there will be plenty of other bugs.

We are also spending efforts in documentation and community interaction.
The google group javafxandroid has a pretty active mailinglist. Build 2
the runtime has been downloaded 291 times in 2 weeks, and build 3 has
downloaded 60 times since it was released a couple of hours ago. So there
is definitely community interest and involvement.
Clearly, there is involvement from Oracle as well. Most of the effort so
far has been done by Tomas Brandalik and the Prague team. I was
surprised to see the amount of native code that was already available for

After a few discussions, it has been agreed that we should try to
synchronize as much as possible with the OpenJFX repositories, without
jeopardizing the stability and performance of the main ports, and without
running into legal trouble.

I will run a diff on the current code versus the OpenJFX code, and I will
try to create issues with patches for sending the changes back to
Not all changes can go back to OpenJFX. We had to add a number of classes
that are missing on Dalvik and that are used by OpenJFX, and clearly we
can't commit those in OpenJFX.

We had to make a number of changes to JavaFX files as well, in order to
make them compile with JDK 1.7. Most of these were about removing
and adding implementations for the default interface methods on
I have no clear opinion on how these changed files could somehow be used
from within OpenJFX, but I'm very open to suggestions.

Finally, keep in mind that this is a community effort. Nobody is paying
this, and it is done in our spare time. I'm doing my best to move forward
as soon as I can, but I have other things to work on as well of course.
However, the collaboration between the Java community and Oracle (mainly
Tomas) has been great so far. It is in the interest of anyone working on
with Java to show the world that JavaFX runs on Android devices.

- Johan

Reply via email to