Does Java 8 delay mean less app developer feedback?

[Richard Bair]

>>> I would like to see the code base of what will be JavaFX 8.0, JDK 8
>>> "free". Of course this also means to use a pre-release since OpenJFX 8.0
>>> "1.0" will only be released when OpenJDK 8 will hit the shelves, which
>>> basically means I'm lost with all the numbering :)
>> 
>> NOt sure what you mean?
> 
> I basically didn't understand this: If OpenJFX 8 needs to wait for
> OpenJDK 8 we will see the first release of OpenJFX 8 sometime next year.
> 
> If I understood correctly, what will become OpenJFX 9 will be developed
> inside the OpenJDK 8 timeframe (and co-bundled with Oracle JDK 8). Or
> will it be rather based on early OpenJDK 9 and being developed
> concurrently to OpenJDK 9?.

Our release schedule and everything is aligned with the JDK anyway. So for example, we GA FX 8 at the same time JavaSE 8 goes GA (which is why we jumped from 2 to 8 in the version number so it would be clear which version of FX works with which version of the JRE). So whether we use API from JDK 8 or not, we're not going to GA JavaFX until JDK is GA'd.

Of course we can add API in update releases, so we don't have to wait until Java 9 for the next release of JavaFX with new features -- we can add features in JavaFX 8.1, 8.2, etc (which will ship with the normal update releases for the JDK of the corresponding version numbers).

So FX 9 will ship with Java 9, FX 10 with Java 10, FX 8 with Java 8, FX 8.1 with Java 8.1, etc.

>>> But on a more serious point, I think it would be good to have the first
>>> OpenJFX 8 release to be JDK 7 compatible, and then move on it's
>>> development by gradually introducing JKD8 features, reaching a JDK9
>>> release which is JKD8 compatible, and so on…
>> 
>> What is the advantage? We co-bundle FX with JDK, both are auto-updated together, etc.
> 
> The advantage is to be able to use JavaFX 8 with *JDK 7, if JavaFX 8
> will require a Java 8 runtime then there's no way this can happen.

Because we ship at the same time as the JDK, by the time FX 8 is available, Java 8 is also available. The only advantage to having FX 8 work on Java 7 (or Java 6) is so that a developer could use new FX features on older releases. But this also has the disadvantage of limiting what we can do in a given release. For example, how (or even whether) we implement filtered / sorted observable lists is impacted by whether we have default methods on interfaces available or not. If we couldn't use 8 features until we were shipping 9, that would mean we either have a much different API (which for the sake of argument lets assume the different API would be objectively worse, since such a situation could certainly occur) or have to wait another 3 years before we can ship that new API.

As another example, the Swing interop required changes in the core JDK. That feature would have to be delayed or selectively disabled on older JREs. It ends up being a mess. Instead, by having FX tied to the version of the JDK it ships with, we can make changes on both sides of the equation (in SE and FX) for the features we have.

The downside is that if you are in an org where you cannot cause the JRE to be a recent version, then you are stuck in terms of what you can do with FX.

Richard