On Mon, 10 Apr 2023 at 00:16, Svata Dedic <svatopluk.de...@gmail.com> 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 characterization of the points others have raised in various threads since the start of the year, or you haven't read them?! > First of all, the general idea that "JDK8 is dead" does not seem > correct. Maybe, but it has stopped getting new features, which is all that is now proposed for NetBeans too. If anyone wants to step up to be NetBeans 18's RedHat that is entirely a possibility. In fact, is for any release branch. > As NetBeans platform, and to lesser degree ide cluster, parts of java > cluster (maybe other parts as well) form *application platform*, not a > development environment - any policy change made here will directly > affect these applications. A point I've made time and time again in previous discussion about resolving this (I develop platform applications that use parts of all those clusters too!). In fact, I'd say everything we release via Maven should have a clearly communicated policy on this. If it's not an API for external use, it shouldn't be on Maven Central IMO (I actually do think we should not release the nb cluster here). It's why the proposal notes that "platform" does not just refer to the platform cluster. > Next, the external conditions that would require us ultimately to move > to newer runtime come (considering Java cluster) from Maven and Gradle. > So far, Gradle 8 still declares runtime support for JDK8; Maven 4 alpha, > so far declares the same. I am not aware of plans from those two to drop > JDK8 runtime support soon As far as I know there is currently discussion on Maven 4 having min JDK 11 or min JDK 17. There is this, but it's a rather old thread link now - https://lists.apache.org/thread/woz6pj6686rxmso47zm35vdxs5vt3bqb There are also some good points about businesses holding out on JDK 8, and the speed with which that can adapt when the ecosystem demands it, in there! Yes, seeking current information would be good. But it shows the ecosystem is moving under us. How would you approach making all of that optional? And to what end? Even if it's not Maven 4, we know it'll soon be something else. > To give an example of my own area: I'd love to have > CompletableFuture.defaultExecutor() method for final rewrite of > RequestProcessors to completable futures. But it can be overcomed with > some limitations and ugly implementation. It is not a hard barrier, but > "only" requires significant effort. The use of reflection and multiple code paths to address issues with eg. deprecated for removal features bothers me more. We're talking about everyone else not only putting in "significant effort" in "their areas", which they may not be willing to do, but also adding to the overall maintenance overhead that lands on others. > So before concluding on anything, I propose these action items: > > - (?) anyone in regular touch with Gradle / Maven developers, so they > could share longer-term JDK support plans in their project ? > - (*) get JDK platform stats out of AutoUpdate server logs, should be > available on netbeans vm > - determine critical (unavoidable) external dependencies for platform > cluster; collect their JDK runtime support plans > - collect (non-exhaustive, just known) list of non-platform modules that > are already known to serve as application library. > - collect list of APIs from JDK11, JDK17 desirable to be actually used > in the codebase. > > (*) I volunteer to do this one. (?) I might be able to take this one if > noone else is willing to do so. > > I am sure others could (should) add their own action items, in their > areas of knowledge. It would be helpful not only to decide on JDK8 fate, > but also on designing the migration path from JDK11 later. We should > decide for the best outcome of project users, anyway. And if we can just do it by tomorrow that would be great! :-) 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. 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
