Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Hi, Am Dienstag, dem 11.04.2023 um 11:27 + schrieb Glenn Holmer: > My hope is that the JDK8 gang will see > the error of their ways and come back to the fold after losing the vote. please lets stay civil here. I think it is clear, that there is disagreement, but that does not mean, that one of the groups is better or worse. I think that both camps "JDK 8 should stay" and "JDK 8 is dead" have their points and I also think that the difference is mostly in the weighing of the arguments and drawing conlusions from that. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Yes, they're loading a ton of org.netbeans.modules.cnd modules, which may be keeping them on older versions of NetBeans Platform, meaning that they can't move to later JDKs anyway. Gj On Tue, Apr 11, 2023 at 2:19 PM Neil C Smith wrote: > > On Tue, 11 Apr 2023 at 13:07, Geertjan Wielenga > wrote: > > INFO [org.netbeans.core.startup.NbEvents]: Turning on modules: > > org.openide.util.lookup [8.25.1 20221005-cd0c929e4999] > > Thanks. Old style spec versions (although more recently compiled!) > So that module is currently 8.54. I think it was 8.34 prior to Apache > donation - > https://github.com/emilianbold/netbeans-releases/blob/master/openide.util.lookup/manifest.mf#L4 > > I'm not sure they're a concern for us right now! > > I wonder if they use aspects of old C support? > > Best wishes, > > Neil > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
On Tue, 11 Apr 2023 at 13:07, Geertjan Wielenga wrote: > INFO [org.netbeans.core.startup.NbEvents]: Turning on modules: > org.openide.util.lookup [8.25.1 20221005-cd0c929e4999] Thanks. Old style spec versions (although more recently compiled!) So that module is currently 8.54. I think it was 8.34 prior to Apache donation - https://github.com/emilianbold/netbeans-releases/blob/master/openide.util.lookup/manifest.mf#L4 I'm not sure they're a concern for us right now! I wonder if they use aspects of old C support? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
INFO [org.netbeans.core.startup.NbEvents]: Turning on modules: org.openide.util.lookup [8.25.1 20221005-cd0c929e4999] org.openide.util [8.39.1 20221005-cd0c929e4999] org.openide.modules [7.43.1 20221005-cd0c929e4999] org.netbeans.api.annotations.common/1 [1.24.1 20221005-cd0c929e4999] org.openide.filesystems [8.12.1 20221005-cd0c929e4999] org.openide.awt [7.62.1 20221005-cd0c929e4999] org.netbeans.api.progress/1 [1.38.1 20221005-cd0c929e4999] org.openide.dialogs [7.38.1 20221005-cd0c929e4999] org.netbeans.modules.queries/1 [1.39.1 20221005-cd0c929e4999] org.openide.nodes [7.39.1 20221005-cd0c929e4999] org.openide.windows [6.71.1 20221005-cd0c929e4999] org.netbeans.swing.tabcontrol [1.51.1 20221005-cd0c929e4999] On Tue, Apr 11, 2023 at 1:58 PM Neil C Smith wrote: > > On Tue, 11 Apr 2023 at 12:43, Geertjan Wielenga > wrote: > > To Karl's question -- the cool new look and feels are not included in > > the latest Microchip MPLAB X IDE, so it's quite an old version of the > > NetBeans Platform, ... > > Not necessarily. You have to actively opt in to those. I implemented > as a default in the IDE branding, not the platform, where even > shipping them is optional. > > Is View / IDE log there? If so, what are the versions at the top of > the log - product and module versions should have the NB version and > git hash for anything we've released in the last few years. > > Best wishes, > > Neil > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
On Tue, 11 Apr 2023 at 12:43, Geertjan Wielenga wrote: > To Karl's question -- the cool new look and feels are not included in > the latest Microchip MPLAB X IDE, so it's quite an old version of the > NetBeans Platform, ... Not necessarily. You have to actively opt in to those. I implemented as a default in the IDE branding, not the platform, where even shipping them is optional. Is View / IDE log there? If so, what are the versions at the top of the log - product and module versions should have the NB version and git hash for anything we've released in the last few years. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
I'd say those that are arguing for JDK 8 are representing the traditional NetBeans focus on compatibility and supporting the full range of Java LTS versions. However, unless they step in to actively work on that with others, that is not sustainable given the sheer number and pace of Java releases versus the number of people willing and able to continue to support that. To Karl's question -- the cool new look and feels are not included in the latest Microchip MPLAB X IDE, so it's quite an old version of the NetBeans Platform, which they may therefore be completely happy with and not need to upgrade anyway and so not have any issues with us dropping JDK 8 -- and by the time they upgrade their NetBeans Platform version, they'd probably do the same with their JDK version (which I'll find out when I meet with them). Gj On Tue, Apr 11, 2023 at 1:27 PM Glenn Holmer wrote: > > On 4/11/23 05:55, Geertjan Wielenga wrote: > > Well, what we're trying to do here is keep the whole project together > > and not branch, which comes down to forking. > > When there's an irreconcilable argument about the direction of a > project, it's the only solution. My hope is that the JDK8 gang will see > the error of their ways and come back to the fold after losing the vote. > > -- > Glenn Holmer (Linux registered user #16682) > "After the vintage season came the aftermath -- and Cenbe." > > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
On 4/11/23 05:55, Geertjan Wielenga wrote: > Well, what we're trying to do here is keep the whole project together > and not branch, which comes down to forking. When there's an irreconcilable argument about the direction of a project, it's the only solution. My hope is that the JDK8 gang will see the error of their ways and come back to the fold after losing the vote. -- Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe." - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Can you see in the installed MPLAB app what NetBeans Platform version they use? Karl On 11.04.2023 13:02, Geertjan Wielenga wrote: I download and installed MPLAB X IDE by Microchip today, probably one of the most widely used NetBeans Platform applications, where I see this: Product Version: MPLAB X IDE v6.05 Updates: Updates available Java: 1.8.0_345; OpenJDK 64-Bit Server VM 25.345-b01 Runtime: OpenJDK Runtime Environment 1.8.0_345-b01 System: Mac OS X version 10.15.7 running on x86_64; UTF-8; en_EN (mplab) I have a meeting this evening with Vincent Sheard, Associate Director, Development Tools at Microchip. Of course, as far as we can tell, they have not contributed anything to Apache NetBeans and are essentially profiting from the work we're doing for free. Still, will be good to hear from them what their perspective is (possibly they're going to move away from JDK 8 anyway or even from NetBeans itself to something in a browser, etc). Also, if the vote succeeds, and we announce our intentions in the blog, etc, be aware that organizations may pop up and indicate their concerns etc -- in which case, they'll need to start contributing here actively, whether on the JDK 8 branch or in the main line. Those who do not contribute cannot complain. Gj On Tue, Apr 11, 2023 at 12:55 PM Geertjan Wielenga wrote: Well, what we're trying to do here is keep the whole project together and not branch, which comes down to forking. Gj On Tue, Apr 11, 2023 at 12:19 PM Glenn Holmer wrote: On 4/10/23 10:19, László Kishalmi wrote: There is a way to support old software, and that is called branching. It is that simple. If the JDK8 gang had the courage of their convictions, they'd have forked by now instead of pulling the whole project down. They could call it DeadBeans. -- Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe." - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
I download and installed MPLAB X IDE by Microchip today, probably one of the most widely used NetBeans Platform applications, where I see this: Product Version: MPLAB X IDE v6.05 Updates: Updates available Java: 1.8.0_345; OpenJDK 64-Bit Server VM 25.345-b01 Runtime: OpenJDK Runtime Environment 1.8.0_345-b01 System: Mac OS X version 10.15.7 running on x86_64; UTF-8; en_EN (mplab) I have a meeting this evening with Vincent Sheard, Associate Director, Development Tools at Microchip. Of course, as far as we can tell, they have not contributed anything to Apache NetBeans and are essentially profiting from the work we're doing for free. Still, will be good to hear from them what their perspective is (possibly they're going to move away from JDK 8 anyway or even from NetBeans itself to something in a browser, etc). Also, if the vote succeeds, and we announce our intentions in the blog, etc, be aware that organizations may pop up and indicate their concerns etc -- in which case, they'll need to start contributing here actively, whether on the JDK 8 branch or in the main line. Those who do not contribute cannot complain. Gj On Tue, Apr 11, 2023 at 12:55 PM Geertjan Wielenga wrote: > > Well, what we're trying to do here is keep the whole project together > and not branch, which comes down to forking. > > Gj > > On Tue, Apr 11, 2023 at 12:19 PM Glenn Holmer > wrote: > > > > On 4/10/23 10:19, László Kishalmi wrote: > > > There is a way to support old software, and that is called branching. > > > It is that simple. > > > > If the JDK8 gang had the courage of their convictions, they'd have > > forked by now instead of pulling the whole project down. They could call > > it DeadBeans. > > > > -- > > Glenn Holmer (Linux registered user #16682) > > "After the vintage season came the aftermath -- and Cenbe." > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > > For additional commands, e-mail: dev-h...@netbeans.apache.org > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Well, what we're trying to do here is keep the whole project together and not branch, which comes down to forking. Gj On Tue, Apr 11, 2023 at 12:19 PM Glenn Holmer wrote: > > On 4/10/23 10:19, László Kishalmi wrote: > > There is a way to support old software, and that is called branching. > > It is that simple. > > If the JDK8 gang had the courage of their convictions, they'd have > forked by now instead of pulling the whole project down. They could call > it DeadBeans. > > -- > Glenn Holmer (Linux registered user #16682) > "After the vintage season came the aftermath -- and Cenbe." > > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
On 4/10/23 10:19, László Kishalmi wrote: > There is a way to support old software, and that is called branching. > It is that simple. If the JDK8 gang had the courage of their convictions, they'd have forked by now instead of pulling the whole project down. They could call it DeadBeans. -- Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe." - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
On Tue, 11 Apr 2023 at 07:41, Geertjan Wielenga wrote: > Could a consensus solution be that for all JDK 8 - compatibility > related items, any/all work related to that, we assign those issues to > Svata -- and we try this for one release and see how that goes? If it > fails, then in the release after that, we should all then have > consensus to move away from JDK 8. > > This does not solve the question of when we'll stop supporting a > particular JDK release -- except that it sounds like "forever, as long > as someone turns up to continue to support that release and in fact > does so". Unfortunately this assumes that the workload for continuing to support JDK 8 (or any future legacy JDK) is something that is neatly encapsulated and doesn't permeate everything. We've had at least 4 different threads I can think of on this since the beginning of this year alone. This is the culmination of a lot of discussion, but no further sign of resolution. There are 3 -1's on this thread. There is no requirement for people to express support, but there are 16 people supporting this here alone (7x PMC, 3x committers, 6x community). That does not include the PMC and community members who have +1'd the basis of this proposal on other threads already (I'm not aware of any other -1?). As pointed out above, ASF consensus is not unanimity, it is finding "widespread agreement". If this situation was reversed, would we take a proposal with only 3 people supporting it against a large proportion of our community as sign of widespread agreement to take a course of action? I agree with Michael and Laszlo, the right (as in, at ASF) and only feasible option is to vote and resolve this now, and I intend to proceed with that as originally planned. Because the alternative, the thought of spending another 3 months engaged in yet more draining and damaging discussion, knocking more chunks out of each other, just makes me want to walk away today. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Hi all, Could a consensus solution be that for all JDK 8 - compatibility related items, any/all work related to that, we assign those issues to Svata -- and we try this for one release and see how that goes? If it fails, then in the release after that, we should all then have consensus to move away from JDK 8. This does not solve the question of when we'll stop supporting a particular JDK release -- except that it sounds like "forever, as long as someone turns up to continue to support that release and in fact does so". Gj On Mon, Apr 10, 2023 at 8:32 PM Michael Bien wrote: > > On 10.04.23 06:20, Michael Bien wrote: > > > > Don't let maven distract us here, I only kept mentioning it since that > > was the area I have been working on. The whole java ecosystem moves > > on: Jetty, Jakarta EE, Spring, Jenkins, Maven, Lucene, (...) > > Since I just read the news in my RSS reader: > > ecj, the eclipse compiler did also move from JDK 11 to JDK 17 a few > weeks ago. > > recommended reading (linked comment and PR itself): > > https://github.com/eclipse-jdt/eclipse.jdt.core/issues/886#issuecomment-1479528341 > > best regards, > > -mbien > > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
On 10.04.23 06:20, Michael Bien wrote: Don't let maven distract us here, I only kept mentioning it since that was the area I have been working on. The whole java ecosystem moves on: Jetty, Jakarta EE, Spring, Jenkins, Maven, Lucene, (...) Since I just read the news in my RSS reader: ecj, the eclipse compiler did also move from JDK 11 to JDK 17 a few weeks ago. recommended reading (linked comment and PR itself): https://github.com/eclipse-jdt/eclipse.jdt.core/issues/886#issuecomment-1479528341 best regards, -mbien - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8) - proceed with vote
On 10.04.23 12:45, Neil C Smith wrote: Seriously, we're left with vote this week (maybe with amendment) or punt the decision for another 3 months to happen with NB20. I'm curious what people who've +1'd this so far would prefer to do after taking into account your points / suggestions? I *really* don't want to be the only one making that call, whichever way it falls. +1 for proceeding with the vote soon the way I see this is that the option of a NB LTS release would solve most if not all concerns while being compatible with the proposed policy. Both things are fairly independent from each other, so I don't see how delaying the release policy vote would help here. Everything what could be said probably has been said by now at some point already, the lazy consensus did also not result in an alternative proposal. best regards, michael Thanks, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Well, there is no hatred here, it is a heated debate. It's just beyond my understanding that people with 20+ years of software development experience don't see branching as a viable option. It seems we could not have convinced some of us on our proposal, that's sad. I'm getting tired of this debate, and I think I'm not alone with that. Let's do an official vote then. On Mon, Apr 10, 2023 at 10:41 AM Svata Dedic wrote: > On 10. 04. 23 19:35, Scott Palmer wrote: > > Note that the one example we have been given so far of "Microchip IDE", > if > > it is what I think it is "MPLAB X IDE" ( > > https://www.microchip.com/en-us/tools-resources/develop/mplab-x-ide), > then > > it seems to have Windows 10, Ubuntu 16.04, macOs 10.15 as minimums. Java > > 11 runs on those platforms, and a JRE has been distributed with the > product > > since 5.40. So I continue to search for a real case for Java 8 support. > > Minor correction: the actually distributed JRE is: > OpenJDK Runtime Environment (Zulu 8.64.0.19-CA-linux64) (build > 1.8.0_345-b01) > > -S. > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
On Mon, Apr 10, 2023 at 1:41 PM Svata Dedic wrote: > On 10. 04. 23 19:35, Scott Palmer wrote: > > Note that the one example we have been given so far of "Microchip IDE", > if > > it is what I think it is "MPLAB X IDE" ( > > https://www.microchip.com/en-us/tools-resources/develop/mplab-x-ide), > then > > it seems to have Windows 10, Ubuntu 16.04, macOs 10.15 as minimums. Java > > 11 runs on those platforms, and a JRE has been distributed with the > product > > since 5.40. So I continue to search for a real case for Java 8 support. > > Minor correction: the actually distributed JRE is: > OpenJDK Runtime Environment (Zulu 8.64.0.19-CA-linux64) (build > 1.8.0_345-b01) > > -S. > I didn't mean to suggest the distributed JRE was currently Java 11. I implied that it could easily be Java 11. I.e. moving to Java 11 seems to not be an issue. Azul's OpenJDK build of JDK 11 has the same license terms I believe. Scott
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
On Mon, 10 Apr 2023, 17:45 Jaroslav Tulach, wrote: > Thank you Sváťa for writing this email. It open another "can of worms" in > the "lazy consensus" thread - in my opinion clearly rendering the "lazy > consensus" as obsolete. > In Apache projects, "consensus" means *widespread agreement among people who have decision power*. It does not necessarily mean "unanimity". The project uses documented voting rules to build consensus when discussion is not sufficient. https://community.apache.org/apache-way/apache-project-maturity-model.html It doesn't render it obsolete, it just leads to the next stage of any decision process if that's the only option. Best wishes, Neil
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
On 10. 04. 23 19:35, Scott Palmer wrote: Note that the one example we have been given so far of "Microchip IDE", if it is what I think it is "MPLAB X IDE" ( https://www.microchip.com/en-us/tools-resources/develop/mplab-x-ide), then it seems to have Windows 10, Ubuntu 16.04, macOs 10.15 as minimums. Java 11 runs on those platforms, and a JRE has been distributed with the product since 5.40. So I continue to search for a real case for Java 8 support. Minor correction: the actually distributed JRE is: OpenJDK Runtime Environment (Zulu 8.64.0.19-CA-linux64) (build 1.8.0_345-b01) -S. - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Just to be clear, there is no "hate" on my part. I know the "tone" is hard to communicate via email. I just disagree that Java 8 support should continue in the main codebase. When I suggest that a Java 8 compatible fork is how to proceed, I wish you all the best of success with it. If you have that need I see no reason why you shouldn't be able to pursue it. I don't see the case for Java 8 going forward with new NB releases, and I disagree that that main code should be muddied with any "ifs" to support Java 8. I just don't see that it is worth it. In fact I see it as a net negative to keep dragging out the life of Java 8. We should actively promote moving forward rather than staying in the past. Draw the line, maintain a Java 8 fork if necessary, keep the rest of the code Java 11+ with a policy that is clear about when that support will no longer be guaranteed and how the minimum version is decided. Clean and simple. This is particularly important for an open source project that needs to attract developers. Nobody *wants* to maintain ancient code. Note that the one example we have been given so far of "Microchip IDE", if it is what I think it is "MPLAB X IDE" ( https://www.microchip.com/en-us/tools-resources/develop/mplab-x-ide), then it seems to have Windows 10, Ubuntu 16.04, macOs 10.15 as minimums. Java 11 runs on those platforms, and a JRE has been distributed with the product since 5.40. So I continue to search for a real case for Java 8 support. Scott On Mon, Apr 10, 2023 at 12:46 PM Jaroslav Tulach wrote: > Thank you Sváťa for writing this email. It open another "can of worms" in > the "lazy consensus" thread - in my opinion clearly rendering the "lazy > consensus" as obsolete. > > I still need a bit of time to think about using your email strategically, > but in any case I'm happy. I am no longer the only one who gets all the > hater! > > Thank you Sváťo! > -jt > > ... >
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Hi, So are these "hundreds of people" Oracle customers, Toni customers, both Oracle and Toni customers or any other kind of users, say open source projects? Thanks, Antonio On 8/4/23 14:04, Jaroslav Tulach wrote: You have met hundreds of people using NetBeans Platform in your career (more than I met) and you know how important backward compatibility is for their decisions and their trust in the NetBeans Platform. - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8) - What is the alternative JDK 8 exit strategy?
What is actually the JDK 8 exit strategy of those who vetoed? Since so far none was given. options: a) there is none, the NetBeans project ends when JDK 8 ends (or before that; this would explain frgaal etc) b) NetBeans waits until JDK 8 ends, and is then migrated in big bang fashion to JDK 3x (assuming it is still possible), expecting the same jump from NB users If we actually care about users, we do have to give them an upgrade path too. The pragmatic way of doing this is to have some NetBeans releases which require JDK 8 (we have them already), then have a few releases which require JDK 11 and after that some which require JDK 17 and so forth. The fact that the steps are small is a feature of the new release model! Waiting for the killer-feature before upgrade would be a mistake for long running projects. beside providing an upgrade path, this will also: - improve UX - allow NB to get rid of EOL libs - which reduces virus scanner complains we are periodically getting from admins - and also reduces the probability of an actual security issue without us having an upgrade path available - and it will keep the project somewhat interesting for contributors (this is a non-technical reason but it shouldn't be ignored since NetBeans is a community effort now) The OpenJDK release train isn't waiting for NetBeans, we have to make a decision very soon or it leaves. Neil's proposal is c) and is fully compatible with the notion of long running NB LTS releases which keep supporting JDK 8 if there is sufficient interest for it. Don't get me wrong, a) is actually a perfectly valid strategy. I have seen it often in projects which know they move on from java or expect to be replaced by other projects in future before the support contract ends. But this doesn't work for long running endeavors since those would run into b) and that would be very short sighted. best regards, michael On 10.04.23 01: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
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Thank you Sváťa for writing this email. It open another "can of worms" in the "lazy consensus" thread - in my opinion clearly rendering the "lazy consensus" as obsolete. I still need a bit of time to think about using your email strategically, but in any case I'm happy. I am no longer the only one who gets all the hater! Thank you Sváťo! -jt Dne po 10. 4. 2023 1:16 uživatel Svata Dedic napsal: > 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
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
On Mon, Apr 10, 2023 at 7:26 AM Karl Tauber wrote: > +1 > > On 10.04.2023 14:08, Svata Dedic wrote: > > I am advocating not to drop JDK8 as runtime for NetBeans (extended) > > Platform, as that decision affects NetBeans-based applications. > > Microchip IDE, that mining analytic stuff we had presentation a long > > time ago (but that still IMHO lives), and possibly others. > > > > Changing the _runtime_ requirements for NetBeans platform affects > > application builders - they are often being forgotten in discussions. > > Do we know that those applications are planing to upgrade to > newer/future NetBeans Platform versions? If none of them plan to > upgrade, then the whole discussion is useless... > +1, also what do they get from JDK8 updates? Last time half of the change was patching some tests, there were a few security patches for jars signed with SHA1 and the update of TZ data. I'd imagine, no one is upset that the Virtual Thread feature was not backported... > I think, if a project/application decides to stay with Java 8 because it > is to risky or to expensive to upgrade to Java 11+, why should they > upgrade to a newer NetBeans Platform version? Any upgrade has some risks > and costs. Isn't it more likely that they newer upgrade to latest > NetBeans Platform version? > > > Or the other way around: > if a project decides to stay on 9 year old Java 8, why can't they stay > on NetBeans Platform from 2023? > > > We can't stay forever on Java 8 just because some NB platform > applications still use Java 8 and "maybe" want upgrade to latest NB > version. > > Also what would happen if Karl decides to pull the plug on Java 8 for FlatLAF? Just think about it... There is a way to support old software, and that is called branching. It is that simple.
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
+1 On 10.04.2023 14:08, Svata Dedic wrote: I am advocating not to drop JDK8 as runtime for NetBeans (extended) Platform, as that decision affects NetBeans-based applications. Microchip IDE, that mining analytic stuff we had presentation a long time ago (but that still IMHO lives), and possibly others. Changing the _runtime_ requirements for NetBeans platform affects application builders - they are often being forgotten in discussions. Do we know that those applications are planing to upgrade to newer/future NetBeans Platform versions? If none of them plan to upgrade, then the whole discussion is useless... I think, if a project/application decides to stay with Java 8 because it is to risky or to expensive to upgrade to Java 11+, why should they upgrade to a newer NetBeans Platform version? Any upgrade has some risks and costs. Isn't it more likely that they newer upgrade to latest NetBeans Platform version? Or the other way around: if a project decides to stay on 9 year old Java 8, why can't they stay on NetBeans Platform from 2023? We can't stay forever on Java 8 just because some NB platform applications still use Java 8 and "maybe" want upgrade to latest NB version. And if they really need to upgrade to a future Java 11+ based NB platform, they can upgrade their application to Java 11+ too... Karl - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Hi, Am Montag, dem 10.04.2023 um 13:02 +0200 schrieb Geertjan Wielenga: > My feeling on this discussion is that, yes, it’s unfortunate that we’re > getting to fruitful discussion only at this late stage — but better late > than never and without this useful thread we wouldn’t have been getting > where we’re getting at all. > > Could one way forward be to do a Zoom call with all those invested in this > (and then bring everything decided back to this mailing list) during the > coming week, unless we can already predict that that will not bring us > further. I see no basis for a discussion. There are two people saying, that they would help with working on JDK 8 support, but that does not answer how people not wanting to stay in the past shall be included. Lets stay with the example already establieshed: maven indexer. I was so fed up with this dicussion, that I did the prototype, not the two people that advocated JDK 8 support is a good idea. So why should I expect this to get better in the future? Given that "#4795 Use frgaal compiler to compile NetBeans" was reopend. I have a serious WTF moment. I'm denied access to modern API, but the author wants a backporting compiler? All this accomplishes is getting us further away, from what is Java in my mind. I verifies concerns that were raised by others for previous PRs. At some point NetBeans was cool from me, because it did not reinvent the wheel (Swing vs. SWT). Reality makes me reconsider this. What I'm missing to the "API stability" and "Compatibility" axis is the sustanibilty axis. Seriously arguing for using older, most probably unmaintained libraries will not fly with me. Lucene as one such example is a beast and learning it once is enough, learning it twice, once for serious interest and once for NetBeans JDK 8 support is useless (for me). And the "let then run NetBeans in degraded mode on JDK 8" idea won't fly, because it will cause strage issue, which are not triaged by the JDK 8 interested people. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
On 10. 04. 23 5:40, Laszlo Kishalmi wrote: 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. Correction: I am not advocating that NetBeans IDE supports JDK8 target for the compilation - that I assumed for granted from the previous discussion. I am advocating not to drop JDK8 as runtime for NetBeans (extended) Platform, as that decision affects NetBeans-based applications. Microchip IDE, that mining analytic stuff we had presentation a long time ago (but that still IMHO lives), and possibly others. Changing the _runtime_ requirements for NetBeans platform affects application builders - they are often being forgotten in discussions. Maintenance releases running on JDK8 are not possible, if the core parts of NetBeans start to extensively use JDK11+ APIs 'just for joy from the new'. -S. - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
My feeling on this discussion is that, yes, it’s unfortunate that we’re getting to fruitful discussion only at this late stage — but better late than never and without this useful thread we wouldn’t have been getting where we’re getting at all. Could one way forward be to do a Zoom call with all those invested in this (and then bring everything decided back to this mailing list) during the coming week, unless we can already predict that that will not bring us further. Gj On Mon, 10 Apr 2023 at 12:46, Neil C Smith wrote: > On Mon, 10 Apr 2023 at 00: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) > > Thank you for your input, and for doing so in a detailed way that > doesn't try to sideline the issues people have raised. I've > personally been wanting to see your input on this for the weeks, > months actually, that this conversation has been ongoing. This would > have been more useful to consider prior to this thread and the policy > being written. It's certainly not been written as *my* preferred way > forward (it isn't) but trying to find a way between all the > viewpoints, and with some feedback from the people making them. > > Adding all this on the last day of this thread / day before opening a > vote thread now gives us a dilemma. Do we allow this discussion to > continue to try and find further compromise before voting? We need a > decision before NB18 freeze (well, before 18-rc1 anyway), so that > would likely lead to a need to delay that. Or do we punt the decision > for 3 months? > > There was no intention to "hide" the JDK 11 part. Minimum JDK policy > is literally the title of this thread. Multiple people have suggested > moving (back) to an LTS-1 plan when finally dropping JDK 8 in both > recent and past discussions. It's close I believe to how NetBeans > operated pre-ASF? > > I do think the two things must be decided together. While I disagree > with a lot of Jaroslav's arguments, trust of users, and particularly > platform developers, is key. Part of that is being clear about what > they can realistically expect from us in future, and time to plan for > that. That is one reason for pushing the decision to be made before > we announce 18-rc1, and included in that announcement. Dropping in > NB19 without pre-announcing is wrong IMO. Announcing with rc1 is an > extra impetus for any affected users to test things that impact them. > > Another reason would be the same reason I pushed for the release > schedule - so we don't have to keep repeating these long, draining, > and in this matter damaging, discussions every time! > > > - I do not think that sufficient relevant data for the decision was > > collected; I think that we did not even start to collect it. > > That depends! Certainly enough data on dependencies, or problems in > delivering features and fixes, had been collected to prompt the > conversations in the first place. > > But the relevant data is primarily internal, not external. ASF is > community over code. We rely on what our contributors want to put > their time into. And we cannot promise to deliver what they are not > willing to. And, yes, I realise you are, but one active contributor > still does not an IDE make! :-) > > If any outside platform user is actually bothered about this, they > should be actively contributing and supporting what they care about, > or paying one of the contributors to care for them! As Michael put > it, "skin in the game". I've spent two decades working with > open-source, but it's certainly not to put my free time into doing > somebody else's job for them. > > > 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. > > If that is to happen, that will also involve someone who cares about > that joining the release team .. from NB18! > > > I'd like to emphasize that > > *runtime* compatibility should be treated separately from *development* > > environment requirements. > > I asked a few times previously whether that means you could support an > LTS-2 approach to runtime once JDK 8 is dropped? Or do you think > whatever runtime policy we have should not be linked to the JDK > release schedule, and why? > > > I would also (now) ask to restrict from > > advocating language goodies > > No-one has argued that as a reason AFAIK! This is primarily > dependencies, ecosystem, infrastructure, time for (or impossibility of > in some cases) delivering via optional bridges ... > > > This really mean to *abandon the > > users*, as they will
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
On Mon, 10 Apr 2023 at 00: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) Thank you for your input, and for doing so in a detailed way that doesn't try to sideline the issues people have raised. I've personally been wanting to see your input on this for the weeks, months actually, that this conversation has been ongoing. This would have been more useful to consider prior to this thread and the policy being written. It's certainly not been written as *my* preferred way forward (it isn't) but trying to find a way between all the viewpoints, and with some feedback from the people making them. Adding all this on the last day of this thread / day before opening a vote thread now gives us a dilemma. Do we allow this discussion to continue to try and find further compromise before voting? We need a decision before NB18 freeze (well, before 18-rc1 anyway), so that would likely lead to a need to delay that. Or do we punt the decision for 3 months? There was no intention to "hide" the JDK 11 part. Minimum JDK policy is literally the title of this thread. Multiple people have suggested moving (back) to an LTS-1 plan when finally dropping JDK 8 in both recent and past discussions. It's close I believe to how NetBeans operated pre-ASF? I do think the two things must be decided together. While I disagree with a lot of Jaroslav's arguments, trust of users, and particularly platform developers, is key. Part of that is being clear about what they can realistically expect from us in future, and time to plan for that. That is one reason for pushing the decision to be made before we announce 18-rc1, and included in that announcement. Dropping in NB19 without pre-announcing is wrong IMO. Announcing with rc1 is an extra impetus for any affected users to test things that impact them. Another reason would be the same reason I pushed for the release schedule - so we don't have to keep repeating these long, draining, and in this matter damaging, discussions every time! > - I do not think that sufficient relevant data for the decision was > collected; I think that we did not even start to collect it. That depends! Certainly enough data on dependencies, or problems in delivering features and fixes, had been collected to prompt the conversations in the first place. But the relevant data is primarily internal, not external. ASF is community over code. We rely on what our contributors want to put their time into. And we cannot promise to deliver what they are not willing to. And, yes, I realise you are, but one active contributor still does not an IDE make! :-) If any outside platform user is actually bothered about this, they should be actively contributing and supporting what they care about, or paying one of the contributors to care for them! As Michael put it, "skin in the game". I've spent two decades working with open-source, but it's certainly not to put my free time into doing somebody else's job for them. > 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. If that is to happen, that will also involve someone who cares about that joining the release team .. from NB18! > I'd like to emphasize that > *runtime* compatibility should be treated separately from *development* > environment requirements. I asked a few times previously whether that means you could support an LTS-2 approach to runtime once JDK 8 is dropped? Or do you think whatever runtime policy we have should not be linked to the JDK release schedule, and why? > I would also (now) ask to restrict from > advocating language goodies No-one has argued that as a reason AFAIK! This is primarily dependencies, ecosystem, infrastructure, time for (or impossibility of in some cases) delivering via optional bridges ... > This really mean to *abandon the > users*, as they will not receive any new features or bugfixes. *If* this proposal passed, then there is the option to use the release180 branch for backporting bug fixes to JDK 8 support. Or even features, although why we'd do that is questionable to me, it is an option. I agree with Matthias, the work to continue supporting JDK 8 needs to go to those who want it. That branch can be as active as you or anyone else wants it to be. Any outside user is free to contribute (or sponsor someone to contribute) a backport too. > 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. That's either a deeply unfair
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
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
On Sat, 8 Apr 2023 at 13:05, Jaroslav Tulach wrote: > ...is going to break the promise me, you > and the NetBeans team was giving NetBeans Platform users since 1997! Aside from wondering how dropping JDK 7 support was not breaking the same promise, my message to Toni would be roughly the same as Michael's .. stop making promises you expect others to keep for you. ASF is a do-ocracy, not a do-not-ocracy. The proposal is also already more conservative than some people are pushing for, and designed to advertise in advance what we're doing, in order to support and foster trust of platform users. They're a high priority for me too, although I'm also contributing because I'd like it to have a future ... > I cannot let that "just" happen. ... If the Apache NetBeans project does not listen to its most active current contributors (eg. [1]), or find other people prepared to take on their workload, then it has no future! That really is of no use to platform users. And I'm not prepared to let that "just" happen without trying to do something about it. If you can propose an alternative that in particular Matthias, Michael and Laszlo would all support, and that addresses their concerns, then maybe we might actually be able to find a consensus way forward! https://github.com/apache/netbeans/graphs/contributors Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Thank you Toni for stepping out and publicly sharing your experience as a long time NetBeans Platform consultant. You have met hundreds of people using NetBeans Platform in your career (more than I met) and you know how important backward compatibility is for their decisions and their trust in the NetBeans Platform. Dropping ability of the NetBeans Platform to run on JDK8 needlessly (yes, I am absolutely convinced it is needless; as we can find a way to "Run on JDK8, use JDK11 APIs!" - http://wiki.apidesign.org/wiki/AlternativeImplementation - without dropping JDK8 support fully), is going to break the promise me, you and the NetBeans team was giving NetBeans Platform users since 1997! I cannot let that "just" happen. Thank you for your vote and for helping me not be alone in this "NetBeans Platform heritage" fight. Thank you! -jt Dne středa 5. dubna 2023 18:25:22 CEST, toni.ep...@eppleton.de napsal(a): > -1 > > I agree with Jarda. Having the portability for platforms like Android is > important, and I support the proposed alternative. > > > > Von: Jaroslav Tulach > Datum: Mittwoch, 5. April 2023 um 17:13 > An: dev > Betreff: Re: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK > 8) -1 > > Background: http://wiki.apidesign.org/wiki/Portability > > > Alternative: > > - I will maintain what ever needs to be maintained to keep JDK 8 CI tests > running > > - From Apache NetBeans 19, the minimum JDK required to build and run > the IDE will be JDK 11. > > - The minimum JDK to run and test the NetBeans Platform and modules up to > VSCode & Jackpot remains JDK 8. > > - Usage of JDK11, JDK17, etc. API is possible in dedicated modules via > http:// wiki.apidesign.org/wiki/AlternativeImplementation > > > Justification: > > Writing in Java (a language designed to write once and run everywhere) > greatly increases portability. However there is another axis hurting > portability - the supported JDK version. Of course, should a library be > widely used, it has to support as oldest JDK as possible. These days it is > JDK8 - the primary reason being that Android supports JDK8 - as such, > should a library aspire to be used on Android (as well as regular Java), it > needs to stick to version eight. > > There's transitivity of non-portability - the portability of the final > application cannot be bigger than portability of the least portable library > used. This applies also to 3rd party dependencies a framework or library > has: again their non-portability may negatively affect portability of such > framework or library. > > Of course, writing portable libraries is harder. It requires more work from > the API author, more self-control, more suffering. However such suffering is > justifiable. There is usually a single API writer, but there are many users > to it. What matters is to simplify and improve experience of those API > users - own author suffering doesn't matter that much. > > > # Proposed policy > > > > * Apache NetBeans 18 will be the last release to support running the > > platform on JDK 8. > > > > * From Apache NetBeans 19, the minimum JDK required to build and run > > the IDE or platform will be JDK 11. > > > > * Future releases will take an "LTS-1" strategy for building and > > running (and CI testing) of the IDE and platform. Three JDKs will be > > supported at any one time - the current JDK, plus the previous two LTS > > releases. eg. NetBeans 20 and 21 (Nov 2023 / Feb 2024) will support > > JDK 11, 17 and 21. NetBeans 22 (May 2024) will support JDK 17, 21 and > > 22. > > > > ## Background > > > > The Apache NetBeans IDE has officially required JDK 11 to build and > > run since NetBeans 13 in March 2022. The platform (and unofficially > > the IDE) have continued to support running on JDK 8 - all modules > > requiring a higher JDK must currently be optional. Various tests have > > continued on JDK 8. > > > > This situation is causing issues as workarounds must be found for > > currently non-optional features that have dependencies or other > > requirements for running on a higher JDK (eg. Maven indexing / Lucene > > [1]). It's causing delays, complications and missed testing time in > > integration of new features (eg. problems merging support for EE 10 > > [2]). Supporting an increasing range of JDKs is causing increasing > > workload, both for people and CI. Meeting the challenges of deprecated > > (for removal) features in the JDK is also complicated by the > > additional JDK requirements. > > > > ## Notes > > > > * Apache NetBeans users will continue to be recommended to use the > > current or latest LTS JDK to run the IDE. The IDE will continue to > > support users developing projects for/with JDK 8, for as long as > > nb-javac and other dependencies allow. > > > > * This proposal specifically doesn't address when the default bytecode > > level across the codebase is increased. This can happen when required, > > but non-optional modules would be
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
welcome back, it might be worth mentioning that: - From Apache NetBeans 19, the minimum JDK required to build and run the IDE will be JDK 11. is how we operate since NetBeans 12.x, nobody has to wait for NetBeans 19 for that. I am only pointing this out since some vetoes come from members of the PMC who were mostly inactive in the recent years, so this doesn't surprise me that some details were missed. If you take a look at the readme or download page you should see the requirements of the IDE. Apache is not the make-a-wish foundation. If there is enough interest in JDK 8, put some skin into the game and branch a LTS release (this is fully compatible with the proposal!). The fact that the vetoes come from PMCs in the backseat, blocking a proposal carefully written and thought out from active members (PMCs!) should rise some red flags about the health/sustainability of this project. Not to mention that I think this is fairly disrespectful for everyone who put extra hours into this to keep NetBeans above water. Neil has been our release manager for the past releases and knows NetBeans, the release process and it's problems very well. He has full support of the active PMCs (as visible in this thread) and is getting vetoed by essentially inactive members - unbelievable. thanks, michael On 05.04.23 18:25, toni.ep...@eppleton.de wrote: -1 I agree with Jarda. Having the portability for platforms like Android is important, and I support the proposed alternative. Von: Jaroslav Tulach Datum: Mittwoch, 5. April 2023 um 17:13 An: dev Betreff: Re: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8) -1 Background: http://wiki.apidesign.org/wiki/Portability Alternative: - I will maintain what ever needs to be maintained to keep JDK 8 CI tests running - From Apache NetBeans 19, the minimum JDK required to build and run the IDE will be JDK 11. - The minimum JDK to run and test the NetBeans Platform and modules up to VSCode & Jackpot remains JDK 8. - Usage of JDK11, JDK17, etc. API is possible in dedicated modules via http:// wiki.apidesign.org/wiki/AlternativeImplementation Justification: Writing in Java (a language designed to write once and run everywhere) greatly increases portability. However there is another axis hurting portability - the supported JDK version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is JDK8 - the primary reason being that Android supports JDK8 - as such, should a library aspire to be used on Android (as well as regular Java), it needs to stick to version eight. There's transitivity of non-portability - the portability of the final application cannot be bigger than portability of the least portable library used. This applies also to 3rd party dependencies a framework or library has: again their non-portability may negatively affect portability of such framework or library. Of course, writing portable libraries is harder. It requires more work from the API author, more self-control, more suffering. However such suffering is justifiable. There is usually a single API writer, but there are many users to it. What matters is to simplify and improve experience of those API users - own author suffering doesn't matter that much. # Proposed policy * Apache NetBeans 18 will be the last release to support running the platform on JDK 8. * From Apache NetBeans 19, the minimum JDK required to build and run the IDE or platform will be JDK 11. * Future releases will take an "LTS-1" strategy for building and running (and CI testing) of the IDE and platform. Three JDKs will be supported at any one time - the current JDK, plus the previous two LTS releases. eg. NetBeans 20 and 21 (Nov 2023 / Feb 2024) will support JDK 11, 17 and 21. NetBeans 22 (May 2024) will support JDK 17, 21 and 22. ## Background The Apache NetBeans IDE has officially required JDK 11 to build and run since NetBeans 13 in March 2022. The platform (and unofficially the IDE) have continued to support running on JDK 8 - all modules requiring a higher JDK must currently be optional. Various tests have continued on JDK 8. This situation is causing issues as workarounds must be found for currently non-optional features that have dependencies or other requirements for running on a higher JDK (eg. Maven indexing / Lucene [1]). It's causing delays, complications and missed testing time in integration of new features (eg. problems merging support for EE 10 [2]). Supporting an increasing range of JDKs is causing increasing workload, both for people and CI. Meeting the challenges of deprecated (for removal) features in the JDK is also complicated by the additional JDK requirements. ## Notes * Apache NetBeans users will continue to be recommended to use the current or latest LTS JDK to run the IDE. The IDE will continue to support users developing projects for/with JDK 8, for as long as nb-javac and other dependencies
AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
-1 I agree with Jarda. Having the portability for platforms like Android is important, and I support the proposed alternative. Von: Jaroslav Tulach Datum: Mittwoch, 5. April 2023 um 17:13 An: dev Betreff: Re: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8) -1 Background: http://wiki.apidesign.org/wiki/Portability Alternative: - I will maintain what ever needs to be maintained to keep JDK 8 CI tests running - From Apache NetBeans 19, the minimum JDK required to build and run the IDE will be JDK 11. - The minimum JDK to run and test the NetBeans Platform and modules up to VSCode & Jackpot remains JDK 8. - Usage of JDK11, JDK17, etc. API is possible in dedicated modules via http:// wiki.apidesign.org/wiki/AlternativeImplementation Justification: Writing in Java (a language designed to write once and run everywhere) greatly increases portability. However there is another axis hurting portability - the supported JDK version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is JDK8 - the primary reason being that Android supports JDK8 - as such, should a library aspire to be used on Android (as well as regular Java), it needs to stick to version eight. There's transitivity of non-portability - the portability of the final application cannot be bigger than portability of the least portable library used. This applies also to 3rd party dependencies a framework or library has: again their non-portability may negatively affect portability of such framework or library. Of course, writing portable libraries is harder. It requires more work from the API author, more self-control, more suffering. However such suffering is justifiable. There is usually a single API writer, but there are many users to it. What matters is to simplify and improve experience of those API users - own author suffering doesn't matter that much. > # Proposed policy > > * Apache NetBeans 18 will be the last release to support running the > platform on JDK 8. > > * From Apache NetBeans 19, the minimum JDK required to build and run > the IDE or platform will be JDK 11. > > * Future releases will take an "LTS-1" strategy for building and > running (and CI testing) of the IDE and platform. Three JDKs will be > supported at any one time - the current JDK, plus the previous two LTS > releases. eg. NetBeans 20 and 21 (Nov 2023 / Feb 2024) will support > JDK 11, 17 and 21. NetBeans 22 (May 2024) will support JDK 17, 21 and > 22. > > ## Background > > The Apache NetBeans IDE has officially required JDK 11 to build and > run since NetBeans 13 in March 2022. The platform (and unofficially > the IDE) have continued to support running on JDK 8 - all modules > requiring a higher JDK must currently be optional. Various tests have > continued on JDK 8. > > This situation is causing issues as workarounds must be found for > currently non-optional features that have dependencies or other > requirements for running on a higher JDK (eg. Maven indexing / Lucene > [1]). It's causing delays, complications and missed testing time in > integration of new features (eg. problems merging support for EE 10 > [2]). Supporting an increasing range of JDKs is causing increasing > workload, both for people and CI. Meeting the challenges of deprecated > (for removal) features in the JDK is also complicated by the > additional JDK requirements. > > ## Notes > > * Apache NetBeans users will continue to be recommended to use the > current or latest LTS JDK to run the IDE. The IDE will continue to > support users developing projects for/with JDK 8, for as long as > nb-javac and other dependencies allow. > > * This proposal specifically doesn't address when the default bytecode > level across the codebase is increased. This can happen when required, > but non-optional modules would be free to adopt the minimum JDK as > they need to. > > * Optional modules may continue to require a runtime JDK higher than > the minimum. Should it become necessary, build time optional modules > might be considered - eg. a build on the minimum JDK may exclude > modules that will not run on that JDK at runtime. > > * 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. This is not expected to cover the runtime container as > a whole - https://netbeans.apache.org/tutorials/nbm-runtime-container.html > > * Once NetBeans 19 is released, the NetBeans 18 release branch could > be used to backport and release JDK 8 supporting fixes, subject to any > PMC members wanting to manage those releases. > > * The term "platform" is used in reference to the whole framework of > modules that we release (eg. via Maven), not just the platform > cluster. > > [1] https://github.com/apache/netbeans/pull/4999 > [2] https://github.com/apache/netbeans/pull/4692 > > - >
