Richard Bair richard.bair at
Wed Jun 4 19:10:40 UTC 2014

We’ve been in the practice of having two installs of java 8 — one with jfxrt.jar in the class path and one without it. You can also remove it via setting the ext.classpath if I remember correctly (our main build.gradle is playing this trick I think). That also wipes out Nashorn (which is also in the ext class path) but I think that’s OK in this case.


On Jun 4, 2014, at 12:07 PM, Johan Vos <johan at> wrote:

> As a follow-up on this: I managed to run the retrolambda process in the
> gradle build for each module (rather than in the end unpacking everything).
> There is still the issue with jfxrt.jar on the classpath. Since it is in
> the ext directory, I can't remove it by specifying the Xbootclasspath. I
> tried to prepend the Xbootclasspath in the retrolambda process with the
> classes generated by openjfx, but in that case, they are loaded by the
> System classloader and ignored by retrolambda.
> I'll try to discuss this in the retrolambda project.
> In theory, I could move jre/lib/ext/jfxrt.jar to some temporary directory,
> run retrolambda and move jfxrt.jar back, but that requires root access in
> most cases and it is very ugly.
> Is there a better way to ignore the jfxrt.jar in the Java 8 SDK?
> - Johan
> 2014-05-02 11:43 GMT+02:00 Johan Vos <johan at>:
>> Hi,
>> I was able to refactor all lambda's out of the class files of jfxrt.jar
>> using RetroLambda 1.1.5-SNAPSHOT.jar (after adding the eclipse swt jar to
>> the classpath and removing jfxrt.jar from the bootclasspath).
>> This means that the builds for platforms that don't support invokedynamic
>> should be able to work with the OpenJFX code base.
>> I'll try to add the retrolambda gradle plugin somehow in the openjfx
>> gradle system. As I'm not an expert with gradle, some help would be
>> appreciated.
>> At this moment, I simply unzipped the jfxrt.jar, removed the jfxrt.jar
>> from the lib/ext directory in the Java 8 install, and executed
>> java -Dretrolambda.inputDir=class
>> -Dretrolambda.classpath=class:org.eclipse.swt.gtk.linux.x86_64_3.7.2.v3740f-.jar
>> -Dretrolambda.outputDir=retroclass -javaagent:retrolambda.jar -jar
>> retrolambda.jar
>> It should be possible to optionally do this retrocompiling task during the
>> build of OpenJFX. In my JavaFX-Android applications, I use
>> gradle-retrolambda as follows:
>> buildscript {
>>  repositories {
>>      mavenCentral()
>>  }
>>  dependencies {
>>     classpath 'me.tatarka:gradle-retrolambda:1.3.0'
>>  }
>> }
>> ...
>> apply plugin: 'retrolambda'
>> - Johan

More information about the openjfx-dev mailing list