Does Java 8 delay mean less app developer feedback?
richard.bair at oracle.com
Thu May 2 08:39:24 PDT 2013
The main cost in back porting is, back porting. That is, if the fix basically has to be done differently in the back port due to changes in the surrounding code, then it becomes more expensive. And of course we're trying to do more than we can do already in terms of forward development, so any additional cost is costly :-). The way we generally deal with this is by having support contracts which, among other things, pays for back porting bugs.
If the 2.x code were all open sourced (not going to happen, just saying) then it would be easier to do this as you could provide the back port patch / change set yourself. In the future (when working on 9 for instance) if you needed a back port to 8.0, this should be possible.
Our general practice is to not spend time on back ports (otherwise we will get bogged down and this also makes it harder for us to do the sort of radical refactoring that we need to do in future releases in order to dramatically improve the product over time, since radical refactoring makes it harder to do back ports). Hopefully like I mentioned this can be alleviated in the future when the version you want to back port to is also open source because you could provide the back port change set yourself if we don't do it (one of the many benefits of being open source!).
With FX we are a bit different than the JDK in that we add new features into update releases. One side effect of this is that after 8.0 ships, we won't be switching to 9 for our main development, but rather, we will be switching to 8.1 (or whatever it is called), which has a shorter release timeframe. In such cases there is no need to back port to 8.0 since 8 update train will get the new code / bug fixes. Right now we're just in a tough spot where we're working on a new train (8 vs. 2.x) and the old train isn't open source.
On May 2, 2013, at 12:11 AM, Randahl Fink Isaksen <randahl at rockit.dk> wrote:
> Oracle has delayed Java 8 until Q1 of 2014, which means FX 8 is delayed likewise, I suppose.
> Now, I have identified and filed quite a lot of JavaFX issues, but more and more of them are being targeted for FX8. I would like to provide feedback as the issues are resolved, but I can no longer do that since – like everyone else – I am developing an app using the current JavaFX release. I cannot help but wonder how many other app developers are now providing less feedback, and I fear that this will have a considerable negative impact on the quality of JavaFX. If no feedback is provided on many of the resolved issues until they are finally released all at once in Q1 2014, there is guaranteed to be QA problems – big bang is rarely a viable development strategy.
> I would like to ask if this has been discussed, and if the JavaFX development team has considered moving issues from FX8 back to the ordinary incremental 2.2.x releases to strengthen the collaboration between app developers and API developers.
More information about the openjfx-dev