Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
On 10.04.23 06:20, Michael Bien wrote: Hi Svata, thanks for your detailed response, my reply is inline On 10.04.23 01:16, Svata Dedic wrote: I would also (now) ask to restrict from advocating language goodies agreed. This whole discussion is almost exclusively about APIs and bytecode levels. Language features come just as side effect of a JDK upgrade as bonus on top. Please remember that the published proposal not only covered JDK8's fate, which we argue about right now, but also the idea to drop JDK11 in 2024. and There was an idea to basically tell users with requirements for older JDKs (now 8, 11 in 2024) they should use the last released platform (NB18) that supports their environment. This really mean to *abandon the users*, as they will not receive any new features or bugfixes. While maintenance effort surely requires work if we still support JDK8, porting features (albeit selectively) back to old platform requires even usually much more effort. The offer that platform users do that for us may seem formally correct, but in reality it requires deep knowledge of many parts of the IDE, not just knowledge of the 'system parts' affected by JDK differences. Exemplified on myself, although I could be able to assist to develop bridges for different JDK versions for features determined as necessary for the new codebase (with possible graceful degradation or function disable on old runtimes), I sincerely doubt I would be able to assist with backporting a user-facing feature. I believe this is a general case, as the 'domain knowledge' is far more scarce than the knowledge of system libraries. So the seemingly positive approach, it turns out to be rather offensive in its implications to platform users, which is an outcome I do not like. This could be eventually barely acceptable in case of JDK8, I do not see reasonable to set minimum JDK to 11 at all. The reason is that while JDK8 has support cycle of 11 years (2015 released, 2026 EOLed by RH / IBM), JDK 11 has a super short shorter cycle despite being LTS (2021-24) and JDK17 just 6 years (2021-2027). From this perspective, forcing the users to upgrade JDK 8 > JDK 11 by NB19 in 2023, and then again to JDK17 by (even if ve move OUR deadlines) right during 2024 given the *upstream support ceases for 11* in 10/2024, is ... a very bad idea. I actually disagree here. The worse situation would be to have to upgrade from 8 to 21 or take an even larger leap, since we waited so long that there are no other LTS releases available under the "new" OpenJDK release model. The "new" OpenJDK release model has several LTS releases at the same time. They are shorter, but the migration risk is lower once a project escaped JDK 8 - since it was the last big release (by design!). We can build all clusters and run CV tests on JDK 21 right now already btw (#5653) and made progress with some high priority issues, e.g. #4952, #4904. Neil's/Geertjan's installers ship with the latest JDK, I am also always running NB on a recent JDK for testing purposes. There is always the possibility to encounter migration specific issues, but I don't see us missing a deadline any time soon because of that - I think we can say with good confidence that NetBeans is working fine on JDK 11+. (the majority of tests are now also running on JDK 11) We should move to JDK 11 ASAP since time is running out as you pointed out. I don't see any reason to wait longer just so that we forced to skip LTS versions. I've read the thread again, and I must think there's a lot of heated feelings, but very little of hard data. Let me say I understand (some of) the urge to upgrade and I'd like myself to be able to use some JDK11+ APIs in NB platform (but also pretty sure that other upgrade proponents are interested in *different* sets of APIs). But there are different perspectives - so important IMHO that I am willing to offer my personal time to support older JDKs, too. In fact, *we all* (IMHO and me explicitly included) never went as far as to write down the fact and consolidate the info to get the overall picture. The consolidated list is important so the maintenance burden could become more obvious even to nonbelievers - or, in other hand, the JDK8 preservation may turn not such high barrier, and JDK11 features not as critical to outweigh the JDK8 drop this is not about JDK 11 features specifically. The proposal is about an upgrade policy. This goes beyond JDK 11. Even if JDK 11 would be not super interesting feature wise, it is simply a step to the next LTS release. If it is a boring step - even better for everyone involved. I don't get why fighting the "new" OpenJDK release model is considered a viable option here. for the whole codebase. We do not have AFAIK such an overview. We did not even start to collect such a list, instead of that, the general tone of the discussion was exagerrated "march forward, kill all the
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Hi Svata, thanks for your detailed response, my reply is inline On 10.04.23 01:16, Svata Dedic wrote: I would also (now) ask to restrict from advocating language goodies agreed. This whole discussion is almost exclusively about APIs and bytecode levels. Language features come just as side effect of a JDK upgrade as bonus on top. Please remember that the published proposal not only covered JDK8's fate, which we argue about right now, but also the idea to drop JDK11 in 2024. and There was an idea to basically tell users with requirements for older JDKs (now 8, 11 in 2024) they should use the last released platform (NB18) that supports their environment. This really mean to *abandon the users*, as they will not receive any new features or bugfixes. While maintenance effort surely requires work if we still support JDK8, porting features (albeit selectively) back to old platform requires even usually much more effort. The offer that platform users do that for us may seem formally correct, but in reality it requires deep knowledge of many parts of the IDE, not just knowledge of the 'system parts' affected by JDK differences. Exemplified on myself, although I could be able to assist to develop bridges for different JDK versions for features determined as necessary for the new codebase (with possible graceful degradation or function disable on old runtimes), I sincerely doubt I would be able to assist with backporting a user-facing feature. I believe this is a general case, as the 'domain knowledge' is far more scarce than the knowledge of system libraries. So the seemingly positive approach, it turns out to be rather offensive in its implications to platform users, which is an outcome I do not like. This could be eventually barely acceptable in case of JDK8, I do not see reasonable to set minimum JDK to 11 at all. The reason is that while JDK8 has support cycle of 11 years (2015 released, 2026 EOLed by RH / IBM), JDK 11 has a super short shorter cycle despite being LTS (2021-24) and JDK17 just 6 years (2021-2027). From this perspective, forcing the users to upgrade JDK 8 > JDK 11 by NB19 in 2023, and then again to JDK17 by (even if ve move OUR deadlines) right during 2024 given the *upstream support ceases for 11* in 10/2024, is ... a very bad idea. I actually disagree here. The worse situation would be to have to upgrade from 8 to 21 or take an even larger leap, since we waited so long that there are no other LTS releases available under the "new" OpenJDK release model. The "new" OpenJDK release model has several LTS releases at the same time. They are shorter, but the migration risk is lower once a project escaped JDK 8 - since it was the last big release (by design!). We can build all clusters and run CV tests on JDK 21 right now already btw (#5653) and made progress with some high priority issues, e.g. #4952, #4904. Neil's/Geertjan's installers ship with the latest JDK, I am also always running NB on a recent JDK for testing purposes. There is always the possibility to encounter migration specific issues, but I don't see us missing a deadline any time soon because of that - I think we can say with good confidence that NetBeans is working fine on JDK 11+. (the majority of tests are now also running on JDK 11) We should move to JDK 11 ASAP since time is running out as you pointed out. I don't see any reason to wait longer just so that we forced to skip LTS versions. I've read the thread again, and I must think there's a lot of heated feelings, but very little of hard data. Let me say I understand (some of) the urge to upgrade and I'd like myself to be able to use some JDK11+ APIs in NB platform (but also pretty sure that other upgrade proponents are interested in *different* sets of APIs). But there are different perspectives - so important IMHO that I am willing to offer my personal time to support older JDKs, too. In fact, *we all* (IMHO and me explicitly included) never went as far as to write down the fact and consolidate the info to get the overall picture. The consolidated list is important so the maintenance burden could become more obvious even to nonbelievers - or, in other hand, the JDK8 preservation may turn not such high barrier, and JDK11 features not as critical to outweigh the JDK8 drop this is not about JDK 11 features specifically. The proposal is about an upgrade policy. This goes beyond JDK 11. Even if JDK 11 would be not super interesting feature wise, it is simply a step to the next LTS release. If it is a boring step - even better for everyone involved. I don't get why fighting the "new" OpenJDK release model is considered a viable option here. for the whole codebase. We do not have AFAIK such an overview. We did not even start to collect such a list, instead of that, the general tone of the discussion was exagerrated "march forward, kill all the old stuff, let the (IT) God sort it
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Dear Svata, First of all, I would like you thank you for offering work to support keep JDK8 alive! Though reading through your mail, I'd wonder how JDK was able to evolve beyond Java 8 it had 80+ percent usage in 2018. The secret is that they forked/branched JDK. As you mentioned there are still maintenance releases for JDK8. In the model Neil offered no one is prevented to do maintenance releases for NetBeans 18 (or any previous version of Apache NetBeans if he/she wishes). It seems there are people willing to put work on that. That's really good and appreciated. "Some modules that are of independent use (eg. lookup, utilities, etc.) might be nominated and advertised to continue JDK 8 support for the time being.", that would make the maintenance work easier. It is also being said that "The IDE will continue to support users developing projects for/with JDK 8, for as long as nb-javac and other dependencies allow." . I think the team would understand if we keep our Gradle Tooling library on JDK8 level for the foreseeable future. On the you "offer coding help with compatibility bridges, analysis and/or migration of the code" could be your next side-gig. Companies using aged software shall pay the price. (You can still buy OS/2 named Arca OS at the base price of $129, for a 6 months support). So you can think of, with this change we open a possibility to monetize your NetBeans knowledge. On the data to be collected, well it would nice to see such a data, though I do not think that should affect the decision. However you can use such data to track the importance of keeping the JDK8 (JDK11) support alive. That should erode with time. On 4/9/23 16:16, Svata Dedic wrote: Please remember that the published proposal not only covered JDK8's fate, which we argue about right now, but also the idea to drop JDK11 in 2024. So take my * -1 (at the moment) for JDK8 phase out with NB19; * and ANOTHER -1 to the JDK11 plans as presented in this thread (but that should be discussed separately anyway, not hidden in dropping JDK8 thread) Summary: - I do not think that dropping JDK8 now is a good idea - I do not think that sufficient relevant data for the decision was collected; I think that we did not even start to collect it. - I do think we can find and reach a reasonable compromise. - I propose some action items to make the decision better informed and based. - I offer coding help with compatibility bridges, analysis and/or migration of the code. TL;DR: I'd like to offer some coding support to retain JDK8 as well - but (which IMHO did not happened really during past heated exchanges) need to agree on support scope before committing. I'd like to emphasize that *runtime* compatibility should be treated separately from *development* environment requirements. I would also (now) ask to restrict from advocating language goodies - as there are different options to achieve that, not necessarily requiring the change of the codebase runtime requirements. I will quite from Ernie Rael's post (quoting stats from 2022): even though Java 11 had been available for more than a year. Since then, the balance has shifted between these two LTS release versions. More than 48% of applications are now using Java 11 in production (up from 11.11% in 2020) with Java 8 a close second, capturing 46.45% of applications using the version in production. There was an idea to basically tell users with requirements for older JDKs (now 8, 11 in 2024) they should use the last released platform (NB18) that supports their environment. This really mean to *abandon the users*, as they will not receive any new features or bugfixes. While maintenance effort surely requires work if we still support JDK8, porting features (albeit selectively) back to old platform requires even usually much more effort. The offer that platform users do that for us may seem formally correct, but in reality it requires deep knowledge of many parts of the IDE, not just knowledge of the 'system parts' affected by JDK differences. Exemplified on myself, although I could be able to assist to develop bridges for different JDK versions for features determined as necessary for the new codebase (with possible graceful degradation or function disable on old runtimes), I sincerely doubt I would be able to assist with backporting a user-facing feature. I believe this is a general case, as the 'domain knowledge' is far more scarce than the knowledge of system libraries. So the seemingly positive approach, it turns out to be rather offensive in its implications to platform users, which is an outcome I do not like. This could be eventually barely acceptable in case of JDK8, I do not see reasonable to set minimum JDK to 11 at all. The reason is that while JDK8 has support cycle of 11 years (2015 released, 2026 EOLed by RH / IBM), JDK 11 has a super short shorter cycle despite being LTS (2021-24) and JDK17 just 6 years
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Please remember that the published proposal not only covered JDK8's fate, which we argue about right now, but also the idea to drop JDK11 in 2024. So take my * -1 (at the moment) for JDK8 phase out with NB19; * and ANOTHER -1 to the JDK11 plans as presented in this thread (but that should be discussed separately anyway, not hidden in dropping JDK8 thread) Summary: - I do not think that dropping JDK8 now is a good idea - I do not think that sufficient relevant data for the decision was collected; I think that we did not even start to collect it. - I do think we can find and reach a reasonable compromise. - I propose some action items to make the decision better informed and based. - I offer coding help with compatibility bridges, analysis and/or migration of the code. TL;DR: I'd like to offer some coding support to retain JDK8 as well - but (which IMHO did not happened really during past heated exchanges) need to agree on support scope before committing. I'd like to emphasize that *runtime* compatibility should be treated separately from *development* environment requirements. I would also (now) ask to restrict from advocating language goodies - as there are different options to achieve that, not necessarily requiring the change of the codebase runtime requirements. I will quite from Ernie Rael's post (quoting stats from 2022): even though Java 11 had been available for more than a year. Since then, the balance has shifted between these two LTS release versions. More than 48% of applications are now using Java 11 in production (up from 11.11% in 2020) with Java 8 a close second, capturing 46.45% of applications using the version in production. There was an idea to basically tell users with requirements for older JDKs (now 8, 11 in 2024) they should use the last released platform (NB18) that supports their environment. This really mean to *abandon the users*, as they will not receive any new features or bugfixes. While maintenance effort surely requires work if we still support JDK8, porting features (albeit selectively) back to old platform requires even usually much more effort. The offer that platform users do that for us may seem formally correct, but in reality it requires deep knowledge of many parts of the IDE, not just knowledge of the 'system parts' affected by JDK differences. Exemplified on myself, although I could be able to assist to develop bridges for different JDK versions for features determined as necessary for the new codebase (with possible graceful degradation or function disable on old runtimes), I sincerely doubt I would be able to assist with backporting a user-facing feature. I believe this is a general case, as the 'domain knowledge' is far more scarce than the knowledge of system libraries. So the seemingly positive approach, it turns out to be rather offensive in its implications to platform users, which is an outcome I do not like. This could be eventually barely acceptable in case of JDK8, I do not see reasonable to set minimum JDK to 11 at all. The reason is that while JDK8 has support cycle of 11 years (2015 released, 2026 EOLed by RH / IBM), JDK 11 has a super short shorter cycle despite being LTS (2021-24) and JDK17 just 6 years (2021-2027). From this perspective, forcing the users to upgrade JDK 8 > JDK 11 by NB19 in 2023, and then again to JDK17 by (even if ve move OUR deadlines) right during 2024 given the *upstream support ceases for 11* in 10/2024, is ... a very bad idea. I've read the thread again, and I must think there's a lot of heated feelings, but very little of hard data. Let me say I understand (some of) the urge to upgrade and I'd like myself to be able to use some JDK11+ APIs in NB platform (but also pretty sure that other upgrade proponents are interested in *different* sets of APIs). But there are different perspectives - so important IMHO that I am willing to offer my personal time to support older JDKs, too. In fact, *we all* (IMHO and me explicitly included) never went as far as to write down the fact and consolidate the info to get the overall picture. The consolidated list is important so the maintenance burden could become more obvious even to nonbelievers - or, in other hand, the JDK8 preservation may turn not such high barrier, and JDK11 features not as critical to outweigh the JDK8 drop for the whole codebase. We do not have AFAIK such an overview. We did not even start to collect such a list, instead of that, the general tone of the discussion was exagerrated "march forward, kill all the old stuff, let the (IT) God sort it later". Also note that we can *lower* the guarantees: e.g. not run JDK8 tests every commit, to reduce the resource consumption for the test matrix. But such negotiation didn't really happen. So far, the major +1s were not based on technical details, but rather on emotions or feelings - "new is good", or at least the thread reads. First of all, the
