Well, your proposal is actually putting additional work both on who wants to move forward and who wants to support Java 8 runtime. Also how would it look like wne Java 17, 21 would be the base? I would like to avoid having codes in the ide like this one: https://github.com/apache/netbeans/blob/7f8dfdeb60ce3bec5554fc19ddb40fac0388d885/extide/gradle/netbeans-gradle-tooling/src/main/java/org/netbeans/modules/gradle/tooling/NbProjectInfoBuilder.java#L1090
And also not everything is coming through Lookup. Yes additional interfaces could be introduced, yes. This could work in a small scale, in a model where we have a Java 8 runtime as standard and eventually offer some services to those who run it on Java 11+. Well, I know the feeling, I was still running NetBeans on Java 1.4.1 on OS/2 in 2005. It was not easy to let it Go. However I do not think that there is any scarification that would need to happen. Create a branch from the upcoming NetBeans 18, backporting some PR-s and occasionally release a NetBeans 18.1 18.2 could happen for years. I do not think that anyone would turn their face away, if there would be a request to help that effort every now-and-then. The VOTE thread is open, please cast your vote there. On Tue, Apr 11, 2023 at 8:32 PM Jaroslav Tulach <jaroslav.tul...@gmail.com> wrote: > > With all due respect, that's not an "alternative". It took me two > > I believe my proposal is a real alternative and it is a way to move us > forward > while not giving up on what makes NetBeans Platform unique - while not > giving > up on backward compatibility. > > > reads to distinguish it from the status quo that we've been doing for > > the last 18 months. Even then, in practical terms, it's the same. If > > The core of my alternative proposal is to move forward and support newer > JDKs > properly, where needed via the "Run on JDK8, use JDK11 APIs!" - http:// > wiki.apidesign.org/wiki/AlternativeImplementation > > Are you saying we are using this proposal already for last 18 months? I am > not > aware of that! If I am mistaken, then please point me to few PRs that are > implementing the "Run on JDK8, use JDK11 APIs!" technique! > > I haven't seen this "Run on JDK8, use JDK11 APIs!" used yet! To let us > start, > please give me three problems that could be solved by using JDK 11 APIs > and > I'll create a PR showing how to do that properly via the "Run on JDK8, use > JDK11 APIs!" style. You will all see, it is a simple and viable way to > move > forward. Then we can all copy that approach where needed and you can focus > on > what you care about... > > > maintenance of the JDK 8 tests is something > > ...none of you wants to do. I understand that. You want to focus on what > you > like. Great, go on and focus fully on new JDKs. I'll maintain the old > modules/ > tests for you. > > I don't find that particularly fascinating, but NetBeans Platform backward > compatibility is so close to my heart that I am going to sacrifice myself > and > do this dirty work. At the end, keeping exiting, functional code running, > isn't going to be that much work. > > TL;DR: If my alternative proposal is accepted, we'll start doing things > differently and allow the NetBeans project to move forward while keeping > its > heritage and compatibility. > > Best regards. > -jt > > > Dne čtvrtek 6. dubna 2023 10:16:14 CEST, Neil C Smith napsal(a): > > On Wed, 5 Apr 2023 at 16:13, Jaroslav Tulach <jaroslav.tul...@gmail.com> > > wrote: > > > 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 > > > > With all due respect, that's not an "alternative". It took me two > > reads to distinguish it from the status quo that we've been doing for > > the last 18 months. Even then, in practical terms, it's the same. If > > that was actually working and sustainable, we wouldn't be having all > > the discussion on this in the first place. > > > > It doesn't address any of the main concerns. It's already been > > pointed out that the maintenance of the JDK 8 tests is something of a > > red herring (I would point out you made a similar promise under the > > current policy, but didn't input into the EE 10 issue raised in the > > background). > > > > - How do we handle the issue of currently non-optional modules that > > require JDK 11+, and who is doing the actual work to split them into > > alternative implementations? What happens if there is no viable JDK 8 > > implementation? > > - How do we address the issue of older / unsupported dependencies (eg. > > Lucene, but more inbound) that require a higher JDK? Who is going to > > do that work? > > - How do we handle issues of testing capacity, both ASF's limited CI > > resources and people, and the developer time needed to address > > problems raised on JDK 8 when adding new features and support for JDK > > 21+? > > - How do we address the issue of contributor disengagement, > > particularly amongst our most active contributors? Who do you expect > > to pick all that work up? > > - And, bluntly, from my perspective, who's taking over release > > management for NB19+? > > > > I said I would try and address reasons for blocking consensus by > > adapting the proposal. I will continue to do so if other concerns are > > raised. But I think it's fundamentally impossible to reconcile your > > points with the points raised by others. Therefore, I guess this > > sadly but inevitably moves to a vote thread after we close discussion > > on Monday. > > > > > The minimum JDK to run and test the NetBeans Platform and modules up to > > > VSCode... remains JDK 8. > > > > I don't want to pre-empt Martin's input, which I know is coming, but > > it has been stated multiple times that dropping JDK 8 is not a problem > > for the VSCode plugin ongoing. Other aspects of this proposal I know > > from correspondence may be of concern, and therefore may lead to > > amendments before any vote. > > > > > Justification: > > ... > > > > > There's transitivity of non-portability - the portability of the final > > > application cannot be bigger than portability of the least portable > > > library > > > used. > > > > Couldn't say it any better myself! :-) > > > > 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 > > > >
