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
code)
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!
Steve
On 2013-12-31 3:47 AM, Johan Vos wrote:
Steve,
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
https://javafx-jira.kenai.com/browse/RT-35123
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.
Thanks,
Steve
On 2013-12-20 12:56 PM, Johan Vos wrote:
Hi,
As you might know, 2 months ago I started a community effort for
"porting"
JavaFX to Android. Today, we released build 3 of the JavaFX Android
runtime, which can be downloaded at
https://bitbucket.org/javafxports/android/downloads/dalvik-sdk-b3.zipwith
instructions on how to build applications at
https://bitbucket.org/javafxports/android/wiki/Building%20and%20deploying%20JavaFX%20Applications
Building the runtime itself is explained at
https://bitbucket.org/javafxports/android/wiki/Building%20the%20JavaFX%20Android%20Runtime
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
changes
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
features.
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
of
the runtime has been downloaded 291 times in 2 weeks, and build 3 has
been
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
positively
surprised to see the amount of native code that was already available for
Android.
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
OpenJFX.
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
Function
and adding implementations for the default interface methods on
ObservableList.
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
for
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
or
with Java to show the world that JavaFX runs on Android devices.
- Johan
