JDK-8098398 : Evaluate Retrolambda for Android
  • Type: Sub-task
  • Component: javafx
  • Sub-Component: build
  • Affected Version: 8u20
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-01-15
  • Updated: 2015-06-12
  • Resolved: 2014-10-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Fixed
Description
Evaluate whether we can use Retrolambda to run JavaFX code using lambda expressions on Android.
Comments
Yep, we evaluated Retrolambda and used it.
20-10-2014
As we are using retrolambda in the Dalvik build, I think this issue can be closed?
20-10-2014
Working with NetBeans lambda-izing tool, some 200 files were modified under graphics (see the attached diff). I had to manually fix ���forward references��� issues in few files, one file with ambiguity, the rest compiled without any issues. One file though could not be fixed because two anonymous classes referred to each other (so repositioning can���t help). I���ve compiled the FX for x86 and arm-hard-float and run the jfxrt.jar files through same procedure : unzipping, running retro-lambda, Jarring. X86 version and the arm version behaved the same way as follows: 1. When given as argument to ���java.ext.dirs��� or placed in the class path, I got this error: java.lang.ClassFormatError: Method setValue in class javafx/beans/value/WritableBooleanValue has illegal modifiers: 0x1041 Only when specified in the ���-Xbootclasspath��� flag, FX (retro-lambda-ized) could run. I guess that when jfxrt.jar is part of the boot class path, runtime is not verifying the files (we had this observation in the past with regard to performance issue, if I remember it right. ). I haven���t investigated this problem further. 2. When binary comparing a ���naive��� class (without anonymous classes/lambda expression) before the retro-lambda manipulation with its transformed form after retro-lambda, I saw that it is different in many places beside the version number. I expected to see just a diff in the version number. 3. When I run the retro-lambda-ized jfxrt.jar using the ���-Xbootclasspath��� flag it seems to work fine on linux-x86 and IMX6-arm-hard-float. On linux-x86 host I checked with jdk8 and jdk7. On IMX6-arm-hard-float I used jdk8.
11-02-2014
It works better but still produce non compilable code. Issues with forward references (which I believe an automatic tool can't really fix) and ambiguity.
04-02-2014
I wanted to check RetroLambda on a larger scale piece of code. The most relevant candidate is of course jfxrt.jar with some lambda expressions in it. I installed IntelliJ and ran the inspection procedure it has to find out where I can replace anonymous classes with lambda expressions. Some 80 cases were found under ���modules/graphics��� . Unfortunately the automatic code substitution/refactoring didn't work well. I saw two kinds of errors in the refactored code : 1. Some string errors like putting ���event1��� variable in the new code instead of ���event���. The compiler didn���t like it of course. 2. Forward reference: while referencing variables "to be defined below" in a definition of an anonymous class is OK for the compiler, when the anonymous class is replaced by lambda expression, the compiler reports an error. Repositioning the lambda expression after the variables definition solves the issue. This is not exactly a problem of the refactoring procedure but the overall result is a compilation error. Since this is going to be manual work, I���ll be working on FX 8u20 main branch. I���ll first check the modified code on JDK8, in order to test the integrity of the code substitution. Next, I���ll do the procedure of executing RetroLambda and will test the repackaged code on JDK7.
04-02-2014
Did you try the lambda-izing support in NetBeans? It might work better.
28-01-2014
I also think RetroLambda provides the solution for having "lambda functionality" on Android. It shouldn't be too hard to have a convenience script in RetroLambda for processing jar files rather than class files. The things that worry me more are the defender methods. Currently, ObservableList uses default methods, hence it doesn't run on Android without modifications. This is tracked in https://javafx-jira.kenai.com/browse/RT-35165 About the crash in the drop-down menu: this might be related to https://javafx-jira.kenai.com/browse/RT-34905 and https://bitbucket.org/javafxports/android/issue/18/choicebox-crash
16-01-2014
I���ve downloaded retrolambda-1.1.2.jar from https://github.com/orfjackal/retrolambda and started to work with. The thing that really bothered me was that you have (AFAIK) to use class files as input to the converting application. Working with jar, as one jar in and one jar out, would have made the process easier the less error prone. I guess we need to work with classes if we want to make the conversion of lambda expressions a part of a building process, but still a Jar input option is needed IMO. Short summary: simple Java FX8 application with lambda expression worked fine on Android. The steps to the summary: Since toys��� HelloWorld have some lambda expressions in it (HelloSingleThreadedJFXPanel.java) I thought I���ll give it a try. My first try was to run HelloSanity, which doesn���t use lambda expression but is part of the HelloWorld.jar I���m recreating from the output of retrolambda. HelloSanity launched smoothly on the Android platform and worked fine ��� this was very cool. Two issues I quickly spotted : 1. Using ���tabs and Menus��� -> ���Land��� drop down menu -> ���sea��� is crashing the application. 2. I saw some graphical defects in the menus��� arrows. Beside that (and possibly other bugs which can be fixed) I think that the application is working really good and very responsive. Next, I went to run HelloSingleThreadedJFXPanel which is using a lambda expression. When I launched the application, I got exception from Dalvik because the application is referencing an AWT class. So this is an example for API mismatch . Next I thought I���ll try one other small Java app that I have used for List View scrolling issue (RT-34744) that uses lambda. Since I forgot it also uses ���streams��� I got another exception from Dalvik. So this is another example of API mismatch. Remark: while preparing the code (app + jfxrt) for the android tools to make it a *.apk (this is done in the rt/android-tools scripts not part of the retrolambda process) we should to see if we can verify API usage against Dalvik���s java libraries. In the end, since I really fell into all possible traps, I just added some simple lambda expression to some simple JavaFX app and that worked fine on the device !!!
16-01-2014