HEADS UP: Switched to 1.8 source/target in build (in graphics repository).

[steve.x.northover at oracle.com]

Hi Tom,

The move to JDK8 for JavaFX has made it hard of the open source 
community to port JavaFX to platforms where JDK8 does not exist. 
Further, tools that do not expect JDK8 syntax can no longer parse JavaFX 
source.

There are two sources of incompatibility:
- new JDK8 syntax (lambdas and defenders)
- new JDK8 API (date and time)

JavaFX has been changed to use JDK8 lambdas and defender methods. The 
patch in this JIRA (https://javafx-jira.kenai.com/browse/RT-30339) is 
intended to show how this can be temporarily worked around.  Note that 
it may soon be impossible to do this because there is no JDK7 syntax for 
defenders.

JavaFX has been changed to use JDK8 API.  Porters and tool vendors have 
the option of either implementing the API or deleting it temporarily 
from JavaFX.  For some tool vendors, it may be possible to put JDK7 on 
the class path before JDK8 so JDK7 versions of the class library are 
used for the base classes, but new JDK8 API can be seen.  This will 
allow classes to compile.  At runtime, JDK8 should be used.

There is no long term commitment to maintain compatibility with JDK7.

In the case of Eclipse, I have built the JDK8 Beta JDT plugins and am 
self hosting with them.  I am in the process of evaluating whether they 
will be sufficient.  It is also possible to run Eclipse using the patch 
and put both JDK7 and JDK8 on the build path (JDK7 first).  This will 
allow you to see JDK7 classes first to avoid changes to the base 
libraries.  At runtime, you should run against JDK8.  Neither of these 
solutions is great so we will have to wait and see.

Steve

On 07/05/2013 11:57 AM, Richard Bair wrote:
>> People using Eclipse as their IDE will not have fun with that I guess because their IDE will not compile the code anymore, so one can't use Eclipse anymore to provide patches - nothing you really care I guess.
> Steve, Felipe, or Jonathan would have to comment on what this does to them I guess -- they all use Eclipse for development.
>
>> I don't argue that you should not do this because Eclipse does not yet support it (which is a shame for Eclipse) but you are excluding other VMs who don't support those concepts - most notable invoke dynamic - this makes a community port of JavaFX to iOS fairly impossible.
> I think it would be fairly easy to just filter out those classes and replace the ObservableList with a version that doesn't have the defender methods. We had to do such things to make JavaFX mobile work back in the day. It is a short term problem because VMs and IDEs are going to move forward.
>
> Richard