Does Java 8 delay mean less app developer feedback?

[Kevin Rushforth]

Hi Randahl,

Unless the code is in an area that is completely unchanged (not many of 
those), retargeting issues for earlier releases is not free either, 
since we would still need to port it to FX 8 -- and because of 
additional testing it isn't really even free in that case. We continue 
to evaluate backporting a small number of critical issues, but as 
Richard pointed out, we are not going to do wholesale backporting.

To use the specific example you cited -- 
https://javafx-jira.kenai.com/browse/RT-21415 -- that one would be some 
extra work for FX 2.X and it would produce something that isn't as 
useful as you might expect, since there are quite a few public classes 
that aren't open-sourced in FX 2. We will rely on the fact that by the 
time FX 8 ships, all of the classes that will need to go into a 
javafx-src.zip will be open source. So, no, RT-21415 is not under 
consideration for FX 2.X. Sorry about that.

-- Kevin


Randahl Fink Isaksen wrote:
> Thank you for the insight Richard. I am fully aware that back porting is not free. But rescheduling issues might be. Hence my example 
>
> https://javafx-jira.kenai.com/browse/RT-21415
>
> When I created this issue back in May 2012, I did so, because that issue slows down the development for every NetBeans application developer out there (the lack of source code makes NetBeans unable to show proper variable names when generating code for you).
>
> I have filed a total of 16 unresolved issues that are now scheduled for Lombard/FX8, and I find it hard to believe that solving these requires Java 8 and/or FX8 in all cases.
>
> Please see
>
> https://javafx-jira.kenai.com/issues/?jql=project%20%3D%20RT%20AND%20fixVersion%20%3D%20Lombard%20AND%20status%20%3D%20Open%20AND%20reporter%20in%20%28currentUser%28%29%29%20ORDER%20BY%20resolution%20ASC
>
> Thanks
>
> Randahl
>
>
>
> On May 2, 2013, at 17:39 , Richard Bair <richard.bair at oracle.com> wrote:
>
>   
>> 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.
>>
>> Richard
>>
>> 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.
>>>
>>> Thanks
>>>
>>> Randahl
>>>       
>
>