> > > https://github.com/oracle/nb-javac/pull/12 > > > > Manually written nb-javac is dead. Long live the new nb-javac! > > Firstly, let me say I think that's a great move forward for nb-javac. > And from how I worded that, you probably know I'm going to raise a > "however" .. :-) Not something that might be a showstopper to us > learning to love nb-javac though .. > > > > Let's develop the new `nb-javac` and let's learn to love it! > > We need to unpick that sentence into two parts. If we presume "Let's > develop" means Let *us* develop, then the simple answer is we can't. > Development of nb-javac has to be external and independent.
Right. `nb-javac` is an independent component created with only purpose: To be consumed by (Apache) NetBeans project and help to improve experience of NetBeans Java IDE users. > At the > same time, in my experience from release managing, nb-javac has been > the number one cause of release delays. Somehow those things need to > be reconciled. In order to love nb-javac, surely we would need a long > term, external commitment to develop it, and a surety that the > external project can meet our release requirements? The work on [automatic refactoring of JDK's javac to nb-javac]( https://github.com/oracle/nb-javac/pull/12) shall improve the situation. Just change the JDK's commit to import, run the build, upload the binaries. The previous delays were caused by the need to do manual changes and that is being eliminated by https://github.com/oracle/nb-javac/pull/12. > And I realise > that "external" there is probably going to be mostly if not > exclusively run by people who also happen to be NetBeans committers or > PMC, just not here! > In Dec/Nov 2020 I made a commitment (internally in Oracle) to take over the maintenance of `nb-javac`. The plan https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac and the work in https://github.com/oracle/nb-javac/pull/12 are results of that promise. Btw. the plan mentions JDK17 as the target date - e.g. I assume it is going to take quite some time, before the ownership of `nb-javac` is transferred to me. Certainly I can't provide any estimate neither whether that happens at the end or not. > Assuming that, then can we learn to love it? Well, firstly, as you're > looking at the sources, an audit that every file is really subject to > CPE *may* actually allow, given more recent developments, us to go > back to Apache Legal and request permission to ship nb-javac as a > dependency out of the box. Is that actually a desirable outcome, > particularly considering above? > +100, yes, that's the desirable outcome. Jakub Herkel has just complained about two different ways to use javac in NetBeans - having just one (e.g. automatically generated `nb-javac` from the latest JDK) would be awesome! If it remains an optional dependency, Javac is hard dependency for NetBeans Java IDE (not for PHP, JavaScript parts, etc.) right now. Luckily it comes as a system dependency (from any modern JDK). That means `nb-javac` is ... > then we're left with considering > "Optional means that the component is not required for standard use of > the product or for the product to achieve a desirable level of > quality. ...is an optional dependency. People can use NetBeans on latest JDK and get the same (with https://github.com/oracle/nb-javac/pull/12 it is really the same!) experience. Given JDK17 is going to be an LTS I'd suggest to force NetBeans IDE users to: Either run NetBeans on JDK17 or install nb-javac! > What about editing JDK 19 while running on JDK 17? That would only be possible with `nbjavac@19` running on JDK 17. > Could that also be > addressed by eating our own dog food and running the LSP on the target > VM? That is an unexplored area for me. I assume it is a long road to get there and keep the current level of Java support. Certainly longer than my nb-javac plans: https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac > The key thing being, if nb-javac remains optional, then what > features of the IDE do we continue to consider non-standard or not > wanted by the majority of users? > I believe it is the combination of IDE's JDK/Java features that creates the restrictions. Without `nb-javac` selecting the right JDK matters. With `nb-javac` and any JDK8+ one can run NetBeans IDE and use the latest Java features without any restrictions. > Contrary to the assertion, I'm not sure that everyone hates nb-javac. > I don't! I think we've been staring at a map for a good long while, > may have finally reached the fork in the road that we could see on the > horizon, and are still not quite sure which direction to take. > Choices are always tough. Luckily for me, I don't have a choice. I promised to take away the cost of maintenance from current `nb-javac` maintainers by end of 2021. On the other side I need NetBeans IDE and/or VSNetBeans to run on GraalVM8. I am doing my best to balance these two requirements. -jt
