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: allowing snapshot maven artefacts during build
Hi Eric, Am Mittwoch, dem 15.03.2023 um 18:58 +0100 schrieb Eric Barboni: > > [Temporary use non maven dependencies for external dependencies] > > Or maybe we already have this. > Actually we have a partial solution. Have a look here: https://github.com/apache/netbeans/blob/master/extide/gradle/external/binaries-list For some unknown reason gradle does not distribute the distribution zip via maven central and so we need to download it directly. You can't work around the checksum, but the build system tells you what it would expect, and what it calculated, so you can trivially find the right checksum by doing a priming build. HTH 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, 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