Android Port: Next Steps

tomas.brandalik at oracle.com tomas.brandalik at oracle.com
Thu Jan 9 10:05:35 PST 2014 

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

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 com.sun.prism.es2.ES2Texture.create(ES2Texture.java:103)
>> W/System.err( 1121): 	at com.sun.prism.es2.ES2ResourceFactory.createTexture(ES2ResourceFactory.java:86)
>> W/System.err( 1121): 	at com.sun.prism.impl.ps.PaintHelper.initGradientTextures(PaintHelper.java:118)
>> W/System.err( 1121): 	at com.sun.prism.impl.ps.PaintHelper.getGradientTexture(PaintHelper.java:141)
>> W/System.err( 1121): 	at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:450)
>> W/System.err( 1121): 	at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:385)
>> W/System.err( 1121): 	at com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:847)
>> W/System.err( 1121): 	at com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:607)
>> W/System.err( 1121): 	at com.sun.prism.impl.ps.BaseShaderGraphics.fillRoundRect(BaseShaderGraphics.java:1549)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1110)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:847)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:750)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:571)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2043)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1951)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:225)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2043)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1951)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:225)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2282)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2176)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2202)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2037)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1951)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:225)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2043)
>> W/System.err( 1121): 	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1951)
>> W/System.err( 1121): 	at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:469)
>> W/System.err( 1121): 	at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:324)
>> W/System.err( 1121): 	at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:97)
>> W/System.err( 1121): 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:422)
>> W/System.err( 1121): 	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:279)
>> W/System.err( 1121): 	at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
>> W/System.err( 1121): 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
>> W/System.err( 1121): 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
>> W/System.err( 1121): 	at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129)
>> 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?
>
> Tom
>
> 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.northover at 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
>>> 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.northover at 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
>>>>>
>>>>
>>>

More information about the openjfx-dev mailing list