where to set properties

Johan Vos johan at lodgon.com
Thu Feb 20 11:16:03 PST 2014


Adding to this:
* lambda's won't be a problem. Can be solved with retrolambda, maybe an
enhanced version
* missing classes won't be a problem, since we have a compat-module or can
add them
* modified Java core classes are a problem. If code rely on existing Java
core classes (e.g. the collections) that are modified in Java 8, we have an
issue, since at runtime we use the Dalvik provided core classes that don't
have the new methods.

- Johan


2014-02-20 20:09 GMT+01:00 Johan Vos <johan at lodgon.com>:

> In the end, the dex converter will complain if we have version 0x34 (= 52
> = Java8), so we need to have class files that have the version 0x33 in
> their header.
> But indeed, if we want to compile the lambda-code, we need a Java 8
> compiler. This will then compile to Java 8 class files, and we will have to
> change the version byte in the class files to 0x33.
>
> Note that we don't have support for Streams yet.
>
> - Johan
>
>
> 2014-02-20 20:04 GMT+01:00 Stephen F Northover <
> steve.x.northover at oracle.com>:
>
>  JDK8 is not supported with Dalvik.  However, JavaFX requires JDK8 in two
>> different ways:
>>
>> 1) It requires JDK8 syntax (default methods, lambdas, optional use of
>> final ...)
>> 2) It requires JDK8 class libraries (there are references to classes that
>> are new in JDK8)
>>
>> So far, we have limited and worded around 1) and Johan has implemented
>> the missing classes for 2).
>>
>> My understanding is that RetroLabmda will be used to fix the problems
>> associated with 1).  Since this works on byte codes, JDK8 will need to be
>> used to create the byte codes and compile the syntax.
>>
>> Johan?
>>
>> Steve
>>
>>
>> On 2014-02-20 1:49 PM, Felix Bembrick wrote:
>>
>>  Isn't that because they need to use the Dalvik Java classes and JDK 8
>> is not supported with Dalvik?
>>
>>
>> On 21 February 2014 05:22, Stephen F Northover <
>> steve.x.northover at oracle.com> wrote:
>>
>>>
>>> On 2014-02-19 12:46 PM, Johan Vos wrote:
>>>
>>>> Is there a policy on the location where properties are defined?
>>>> I see there are properties on a number of places:
>>>> build.properties (e.g. jfx.build.jdk.version=1.8.0)
>>>> build.gradle (e.g. ext.JAVA_HOME = JDK_HOME)
>>>> buildSrc/(e.g. linux).gradle (e.g. LINUX.compileSwing = true;)
>>>> command line properties (e.g. -Djfx.build.jdk.defenders=true)
>>>>
>>>> The reason I'm asking:
>>>> for Android/Dalvik, we don't require jfxBuildJdkVersion to be 1.8.0.
>>>> There
>>>> are a number of ways to fix this. The current test is
>>>>   if (jdkVersion != jfxBuildJdkVersion) {
>>>>              fail("java version mismatch: ${jdkVersion} must be
>>>> ${jfxBuildJdkVersion}")
>>>>          }
>>>>
>>>> We build the Android/Dalvik runtime with Java 7, hence this check fails.
>>>> We can either change jfx.build.jdk.version in build.properties (but not
>>>> conditionally), or we can skip the test if
>>>> System.getProperty("jfx.build.jdk.defenders) is true, or we can check if
>>>> the OS is Dalvik, or... or...
>>>>
>>>
>>>  Is there a reason why you cannot build with 8?  You will need to accept
>>> 8 syntax (like lambdas).
>>>
>>>
>>>> I don't want to pollute the build files with too many tests, so I
>>>> prefer to
>>>> stick to the policy, if there is one.
>>>>
>>>> Thanks,
>>>>
>>>> - Johan
>>>>
>>>
>>>
>>
>>
>


More information about the openjfx-dev mailing list