Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Some minimum JDK level needs to be specified. While this is basically arbitrary based on the needs of the platform and work required to support it, I think it makes sense that the minimum should be some LTS version. To get the widest audience would suggest that version should be the oldest LTS still supported at the time of release. That would mean any release prior to September 2023 should have JDK 11 as the minimum and not anything more recent. If that minimum is considered too old for any reason then the next JDK to consider should be the next LTS release after JDK 11. Is there an argument for considering non-LTS releases? I suggest those primarily because it seems they would be the JDKs most likely to be picked in general for any arbitrary company, dependency, or whatever. Releases between LTS releases are likely to be selected only when they contain a particular needed feature. I think it should go without saying that whatever JDK is selected as the minimum, no incubating or preview features should be used. That just opens another can of worms. At the same time the expectation of users is that NetBeans will support the current JDK for development. Ideally coding for EA releases should work on a best-efforts basis. How are we to evaluate EA releases if our tools won't support them? While NB must require some minimum version, it is not unreasonable to require it to run on a more recent version in order to support more recent JDKs. My point being that I don't see an issue if running NB on JDK 11 means you can't properly work with a project that needs JDK 19. If you need to run on JDK 19 to develop for JDK 19, that's fair. Personally, I think it is important to make the jump away from JDK 8. It matters far less how far that jump is. JDK 11 would perhaps be the least disruptive option in what is certainly going to be a disruptive transition for some. But the difference from JDK 11 to JDK 17 is insignificant in comparison to JDK 8 to 11. If you're going to break compatibility, why drag your feet? Move forward as far as you can and sit there for a while with a stable target JDK version, rather than tip-toeing one step at a time trickling a few disruptions in at every release. My 2c, Scott
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Hi Neil, Am Donnerstag, dem 16.03.2023 um 11:23 + schrieb Neil C Smith: > Hi Matthias, > > On Sun, 12 Feb 2023 at 22:22, Neil C Smith wrote: > > On Sun, 12 Feb 2023, 19:11 Matthias Bläsing, > > wrote: > > > > > > Hi, > > > > > > Am Freitag, dem 10.02.2023 um 10:12 + schrieb Neil C Smith: > > > > On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing > > > > wrote: > > > > > - commit to make NetBeans runnable on JDK LTS -1 > > > > > - build with JDK LTS -1 > > > > > - be able to be build with the current JDK > > > > > > > > +1 as long as that includes the platform. > > > > > > > > That is what I suggested in the other thread (I don't see why we need > > > > multiple threads incidentally!) > > > > > > > > An LTS-1 strategy seems closest to how NetBeans used to function - > > > > major-1, in a time when it also had more development resources? > > > > > > > > Let's also be clear, though, that adopting an LTS-1 strategy means > > > > dropping JDK 11 support either in our first release after JDK 21, or > > > > the first after JDK 22 - so latest May 2024. > > > > > > why would we do that? I said _runnable_ and _buildable_. As long as the > > > current JDK support the target release I did not exclude that. > > > > > > In which case I don't understand what you mean by committing to make > > NetBeans buildable and runnable on LTS-1? That to me means dropping the > > commitment to JDK 11 when it becomes LTS-2. > > I'd still really like to see us make some movement here before the > next release freeze in a month. > > I'd still like to understand whether we're saying the same or > different things about adopting an LTS-1 strategy here? what I think I wanted to say is, that we don't need to raise the bytecode level for the whole codebase and could keep most modules on language level 8, but give developers the option to raise it to LTS-1 if necessary. The definition of necessary might be a matter of dicussion. This would give people who aim for compatibility with JDK 8 for some modules the handle to work with NetBeans and get their wishes. External dependencies might cause us to be required to raise the Java level over LTS - 1. Some libraries might evolve faster than we like and we might not be able to work with the LTS - 1 compatbile version. This then also means, that the build JDK would be required to be current or current-1. I think generally aiming for compatibilty with LTS - 1 would be a good compromise. Greetings Matthias, not sure if this really helped to clear things up - 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: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
On Thu, 16 Mar 2023 at 11:46, Svata Dedic wrote: > I see the rapid movement between > JDK versions that is even increasing with increased frequency of JDK > releases (with only limited features that make a real difference for NB > development) as dangerous But also a reality we don't control, and affects not just us but the ecosystem we rely on. > In my current state of mind / evaluation of the issue I'd give -0.5 to > JDK8 drop and -infinity to JDK11 drop next year. I'll try to catch up > with the conversation during till next week - the stated position needs > more elaborate explanation, but I don't want to repeat others (too > much). Thanks. Fair enough. It would be good to link the -1's (or -0.5 to -infinity :-) ) to alternative answers to the problems we face though. On JDK 8, how would you envisage solving eg. the Maven indexer issues, or other (currently) non-optional dependencies and modules needing access to JDK 11+ APIs? Who is going to do the extra work that will lead to? On not dropping JDK 11 next year, what supported matrix of JDKs do you think we should aim for with the platform and the IDE? Do you think we should support and test across 4+ concurrent JDK's - JDK 11, 17 and 21 LTS as well as current? Where are the resources, CI, manpower and release testing for that? Do you support an LTS-2 strategy, dropping JDK 11 when JDK 25 is out? Or is the JDK LTS status irrelevant in choosing our support matrix, and if so what should that be based on? 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: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Speaking for myself personally: I'd like to step in the discussion, as I see the rapid movement between JDK versions that is even increasing with increased frequency of JDK releases (with only limited features that make a real difference for NB development) as dangerous - but I still lag behind as I am trying to read the whole thread. In my current state of mind / evaluation of the issue I'd give -0.5 to JDK8 drop and -infinity to JDK11 drop next year. I'll try to catch up with the conversation during till next week - the stated position needs more elaborate explanation, but I don't want to repeat others (too much). Thanks. -Svata On 16. 03. 23 12:23, Neil C Smith wrote: Hi Matthias, On Sun, 12 Feb 2023 at 22:22, Neil C Smith wrote: On Sun, 12 Feb 2023, 19:11 Matthias Bläsing, wrote: Hi, Am Freitag, dem 10.02.2023 um 10:12 + schrieb Neil C Smith: On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing wrote: - commit to make NetBeans runnable on JDK LTS -1 - build with JDK LTS -1 - be able to be build with the current JDK +1 as long as that includes the platform. That is what I suggested in the other thread (I don't see why we need multiple threads incidentally!) An LTS-1 strategy seems closest to how NetBeans used to function - major-1, in a time when it also had more development resources? Let's also be clear, though, that adopting an LTS-1 strategy means dropping JDK 11 support either in our first release after JDK 21, or the first after JDK 22 - so latest May 2024. why would we do that? I said _runnable_ and _buildable_. As long as the current JDK support the target release I did not exclude that. In which case I don't understand what you mean by committing to make NetBeans buildable and runnable on LTS-1? That to me means dropping the commitment to JDK 11 when it becomes LTS-2. I'd still really like to see us make some movement here before the next release freeze in a month. I'd still like to understand whether we're saying the same or different things about adopting an LTS-1 strategy here? 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: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Hi Matthias, On Sun, 12 Feb 2023 at 22:22, Neil C Smith wrote: > On Sun, 12 Feb 2023, 19:11 Matthias Bläsing, > wrote: >> >> Hi, >> >> Am Freitag, dem 10.02.2023 um 10:12 + schrieb Neil C Smith: >> > On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing >> > wrote: >> > > - commit to make NetBeans runnable on JDK LTS -1 >> > > - build with JDK LTS -1 >> > > - be able to be build with the current JDK >> > >> > +1 as long as that includes the platform. >> > >> > That is what I suggested in the other thread (I don't see why we need >> > multiple threads incidentally!) >> > >> > An LTS-1 strategy seems closest to how NetBeans used to function - >> > major-1, in a time when it also had more development resources? >> > >> > Let's also be clear, though, that adopting an LTS-1 strategy means >> > dropping JDK 11 support either in our first release after JDK 21, or >> > the first after JDK 22 - so latest May 2024. >> >> why would we do that? I said _runnable_ and _buildable_. As long as the >> current JDK support the target release I did not exclude that. > > > In which case I don't understand what you mean by committing to make NetBeans > buildable and runnable on LTS-1? That to me means dropping the commitment to > JDK 11 when it becomes LTS-2. I'd still really like to see us make some movement here before the next release freeze in a month. I'd still like to understand whether we're saying the same or different things about adopting an LTS-1 strategy here? 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
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
(Apologies if you see this twice. First sent this 3 hours ago. It was not delivered to me; anyone?) As Neil says The question is whether it is worth it? And Scott An informed decision needs to be based on these details. Holding back for JDK 8 compatibility helps no one if there isn't actually any real demand to do so. AFAICT, there's no stats on JDK version and NBP projects. Maybe the closest is general JDK usage, I don't know how well they relate, but it's the best we've got. Last year, there were reports that JDK-8/JDK-11 were neck and neck at somewhat under 50 percent, with JDK-11 and JDK-17 picking up steam. So where's JDK-8 this year? An estimate might be 33%. If one third of users are on JDK-8, is that a real demand? Definitely JDK-8 usage is going down, how steeply? (Plenty of hand waving, but worth trying to base the discussion on fact.) One question, what is the point below which there's no real demand and it's not worth it? -ernie On 23/02/12 2:22 PM, Neil C Smith wrote: On Sun, 12 Feb 2023, 19:11 Matthias Bläsing, wrote: Hi, Am Freitag, dem 10.02.2023 um 10:12 + schrieb Neil C Smith: On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing wrote: - commit to make NetBeans runnable on JDK LTS -1 - build with JDK LTS -1 - be able to be build with the current JDK +1 as long as that includes the platform. That is what I suggested in the other thread (I don't see why we need multiple threads incidentally!) An LTS-1 strategy seems closest to how NetBeans used to function - major-1, in a time when it also had more development resources? Let's also be clear, though, that adopting an LTS-1 strategy means dropping JDK 11 support either in our first release after JDK 21, or the first after JDK 22 - so latest May 2024. why would we do that? I said _runnable_ and _buildable_. As long as the current JDK support the target release I did not exclude that. In which case I don't understand what you mean by committing to make NetBeans buildable and runnable on LTS-1? That to me means dropping the commitment to JDK 11 when it becomes LTS-2. - keep as many modules as feasible compatible with release 8 -1 : A number of things have come up recently about preparing for JDK 21+ that would involve increasing the bytecode level and APIs in some core parts of the NetBeans runtime container. Could you elaborate what that is? Not using Thread#stop and dropping finalizers is it not. That can be done (with some pain) with support for 8. So what is the problem? Yes, those and I think some others. My paragraph after the one you quoted was acknowledging we can do this for 8 with some pain (headache). The question is whether it is worth it? Best wishes, Neil
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
As Neil says The question is whether it is worth it? And Scott An informed decision needs to be based on these details. Holding back for JDK 8 compatibility helps no one if there isn't actually any real demand to do so. AFAICT, there's no stats on JDK version and NBP projects. Maybe the closest is general JDK usage, I don't know how well they relate, but it's the best we've got. Last year, there were reports that JDK-8/JDK-11 were neck and neck at somewhat under 50 percent, with JDK-11 and JDK-17 picking up steam. So where's JDK-8 this year? An estimate might be 33%. If one third of users are on JDK-8, is that a real demand? Definitely JDK-8 usage is going down, how steeply? (Plenty of hand waving, but worth trying to base the discussion on fact.) One question, what is the point below which there's no real demand and it's not worth it? -ernie On 23/02/12 2:22 PM, Neil C Smith wrote: On Sun, 12 Feb 2023, 19:11 Matthias Bläsing, wrote: Hi, Am Freitag, dem 10.02.2023 um 10:12 + schrieb Neil C Smith: On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing wrote: - commit to make NetBeans runnable on JDK LTS -1 - build with JDK LTS -1 - be able to be build with the current JDK +1 as long as that includes the platform. That is what I suggested in the other thread (I don't see why we need multiple threads incidentally!) An LTS-1 strategy seems closest to how NetBeans used to function - major-1, in a time when it also had more development resources? Let's also be clear, though, that adopting an LTS-1 strategy means dropping JDK 11 support either in our first release after JDK 21, or the first after JDK 22 - so latest May 2024. why would we do that? I said _runnable_ and _buildable_. As long as the current JDK support the target release I did not exclude that. In which case I don't understand what you mean by committing to make NetBeans buildable and runnable on LTS-1? That to me means dropping the commitment to JDK 11 when it becomes LTS-2. - keep as many modules as feasible compatible with release 8 -1 : A number of things have come up recently about preparing for JDK 21+ that would involve increasing the bytecode level and APIs in some core parts of the NetBeans runtime container. Could you elaborate what that is? Not using Thread#stop and dropping finalizers is it not. That can be done (with some pain) with support for 8. So what is the problem? Yes, those and I think some others. My paragraph after the one you quoted was acknowledging we can do this for 8 with some pain (headache). The question is whether it is worth it? 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: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
While I appreciate Jaroslav's point about libraries being compatible with a wide variety of Java versions, we do have to balance that with keeping up with recent developments and the extra effort it entails to avoid using modern features that are otherwise available. I personally don't see an issue in dropping Java 8 as a minimum platform for building or running NetBeans. If you want to run on Java 8, you are already accustomed to living in the past - you can deal with an older version of NB or the NB platform that supports Java 8. I say that however, having no stake in a NB platform app. It isn't going to affect me. My vote shouldn't count for much. But NB or the NB platform isn't the only library an application will use, and many others are already starting to raise the bar as far as the minimum supported JDK/JRE. You can only go back as far as all of your dependencies will allow. If there is demand for it, a Java 8 compatible maintenance branch can be made. One reason for running on JDK 8 mentioned running on Android. Are there a significant number of NB platform apps that run on Android now? Do they already build with the latest NB platform, or are they already using an older version anyway - i.e. being on the lastest NB platform may not be a big deal for them. An informed decision needs to be based on these details. Holding back for JDK 8 compatibility helps no one if there isn't actually any real demand to do so. Just my 2c, Scott On Sun, Feb 12, 2023 at 5:22 PM Neil C Smith wrote: > On Sun, 12 Feb 2023, 19:11 Matthias Bläsing, > wrote: > > > Hi, > > > > Am Freitag, dem 10.02.2023 um 10:12 + schrieb Neil C Smith: > > > On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing < > mblaes...@doppel-helix.eu.invalid> > > wrote: > > > > - commit to make NetBeans runnable on JDK LTS -1 > > > > - build with JDK LTS -1 > > > > - be able to be build with the current JDK > > > > > > +1 as long as that includes the platform. > > > > > > That is what I suggested in the other thread (I don't see why we need > > > multiple threads incidentally!) > > > > > > An LTS-1 strategy seems closest to how NetBeans used to function - > > > major-1, in a time when it also had more development resources? > > > > > > Let's also be clear, though, that adopting an LTS-1 strategy means > > > dropping JDK 11 support either in our first release after JDK 21, or > > > the first after JDK 22 - so latest May 2024. > > > > why would we do that? I said _runnable_ and _buildable_. As long as the > > current JDK support the target release I did not exclude that. > > > > In which case I don't understand what you mean by committing to make > NetBeans buildable and runnable on LTS-1? That to me means dropping the > commitment to JDK 11 when it becomes LTS-2. > > > > > > > - keep as many modules as feasible compatible with release 8 > > > > > > -1 : A number of things have come up recently about preparing for JDK > > > 21+ that would involve increasing the bytecode level and APIs in some > > > core parts of the NetBeans runtime container. > > > > Could you elaborate what that is? Not using Thread#stop and dropping > > finalizers is it not. That can be done (with some pain) with support > > for 8. So what is the problem? > > > > Yes, those and I think some others. My paragraph after the one you quoted > was acknowledging we can do this for 8 with some pain (headache). The > question is whether it is worth it? > > Best wishes, > > Neil >
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
On Sun, 12 Feb 2023, 19:11 Matthias Bläsing, wrote: > Hi, > > Am Freitag, dem 10.02.2023 um 10:12 + schrieb Neil C Smith: > > On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing > > > wrote: > > > - commit to make NetBeans runnable on JDK LTS -1 > > > - build with JDK LTS -1 > > > - be able to be build with the current JDK > > > > +1 as long as that includes the platform. > > > > That is what I suggested in the other thread (I don't see why we need > > multiple threads incidentally!) > > > > An LTS-1 strategy seems closest to how NetBeans used to function - > > major-1, in a time when it also had more development resources? > > > > Let's also be clear, though, that adopting an LTS-1 strategy means > > dropping JDK 11 support either in our first release after JDK 21, or > > the first after JDK 22 - so latest May 2024. > > why would we do that? I said _runnable_ and _buildable_. As long as the > current JDK support the target release I did not exclude that. > In which case I don't understand what you mean by committing to make NetBeans buildable and runnable on LTS-1? That to me means dropping the commitment to JDK 11 when it becomes LTS-2. > > > - keep as many modules as feasible compatible with release 8 > > > > -1 : A number of things have come up recently about preparing for JDK > > 21+ that would involve increasing the bytecode level and APIs in some > > core parts of the NetBeans runtime container. > > Could you elaborate what that is? Not using Thread#stop and dropping > finalizers is it not. That can be done (with some pain) with support > for 8. So what is the problem? > Yes, those and I think some others. My paragraph after the one you quoted was acknowledging we can do this for 8 with some pain (headache). The question is whether it is worth it? Best wishes, Neil
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Hi, Am Freitag, dem 10.02.2023 um 10:12 + schrieb Neil C Smith: > On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing > wrote: > > - commit to make NetBeans runnable on JDK LTS -1 > > - build with JDK LTS -1 > > - be able to be build with the current JDK > > +1 as long as that includes the platform. > > That is what I suggested in the other thread (I don't see why we need > multiple threads incidentally!) > > An LTS-1 strategy seems closest to how NetBeans used to function - > major-1, in a time when it also had more development resources? > > Let's also be clear, though, that adopting an LTS-1 strategy means > dropping JDK 11 support either in our first release after JDK 21, or > the first after JDK 22 - so latest May 2024. why would we do that? I said _runnable_ and _buildable_. As long as the current JDK support the target release I did not exclude that. > > - keep as many modules as feasible compatible with release 8 > > -1 : A number of things have come up recently about preparing for JDK > 21+ that would involve increasing the bytecode level and APIs in some > core parts of the NetBeans runtime container. Could you elaborate what that is? Not using Thread#stop and dropping finalizers is it not. That can be done (with some pain) with support for 8. So what is the problem? > We could choose to keep release 8 for some modules that make sense as > libraries outside of the runtime container - utilities, lookup, etc.? > But surely it makes more sense to explicitly specify those, so that we > and third-parties have clarity over which things still support JDK 8? This might be part of a constructive counter proposal of the "JDK 8 will never die" fraction. 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: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing wrote: > - commit to make NetBeans runnable on JDK LTS -1 > - build with JDK LTS -1 > - be able to be build with the current JDK +1 as long as that includes the platform. That is what I suggested in the other thread (I don't see why we need multiple threads incidentally!) An LTS-1 strategy seems closest to how NetBeans used to function - major-1, in a time when it also had more development resources? Let's also be clear, though, that adopting an LTS-1 strategy means dropping JDK 11 support either in our first release after JDK 21, or the first after JDK 22 - so latest May 2024. > - keep as many modules as feasible compatible with release 8 -1 : A number of things have come up recently about preparing for JDK 21+ that would involve increasing the bytecode level and APIs in some core parts of the NetBeans runtime container. Either we give ourselves more of a headache there to keep JDK 8, or we do this cleanly, at which point raising the default to release 11 makes more sense? We could choose to keep release 8 for some modules that make sense as libraries outside of the runtime container - utilities, lookup, etc.? But surely it makes more sense to explicitly specify those, so that we and third-parties have clarity over which things still support JDK 8? 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
Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Hi, from my POV it is a fact, that NetBeans (the IDE) can't be required to be runnable on JDK 8 and in fact it is not. So my idea: - commit to make NetBeans runnable on JDK LTS -1 - build with JDK LTS -1 - be able to be build with the current JDK - allow modules to depend on libraries, that require newer JDKs (see new JakarataEE developments for example, OpenJFX) - keep as many modules as feasible compatible with release 8 - if a module needs to break compatibility with java 8 it is the job of people wanting it to stay compatible to do the necessary work - the more to the core, the better the arguments for breaking compatibitly should be The idea here is, that I see Jaroslavs point that libraries should be compatible and I'm willing to sacrifice syntactic sugar for compatibility. What I won't accept is that we are stuck in the past. OpenJFX has a webbrowser and thus quickly becomes a security component, we must be able to update this. This also introduces a baseline java version: The absolute lowest support java version is the one still supported by the most current JDK. Greetings Matthias Am Dienstag, dem 10.01.2023 um 15:16 +0100 schrieb Michael Bien: > Hello devs, > > I hope everyone recovered from the last JDK 8 thread and is ready for > the first JDK 8 thread of 2023 :) > > The commit validation job is currently testing on 8, 11, 17 and 20-ea. > It doesn't like NetBeans editor modules which require java 11 though > which blocks a Jakarta EE 10 PR atm (#4692). > > This means we need either 1) a volunteer who would like to spend time > and fix JDK 8 tests, 2) we remove JDK 8 from the CV test matrix or 3) we > won't be able to merge this pr before freeze. > > Given that NB doesn't really support running on JDK 11 since a while I > would simply opt for 2) and merge. > > The problem is that I don't know the NB VSCode Extension situation very > well. > > Have the NB VSCode Extension specific tests (which run on JDK 8) > sufficient coverage so that we can remove JDK 8 from the CV test matrix? > At what point will JDK 11 modules become a problem for VSCode? When will > the VSCode NB extension bump the runtime requirement to 11? > > The next modules which would require JDK 11 are probably maven related > (#4999) but this wouldn't be for NB 17. > > best regards, > > michael > - 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
