Hi Matthias, thanks for bringing this topic up.
On 4/22/26 21:58, Matthias Bläsing wrote: > Hi, > > a recent PR invoked the nb-javac build of NetBeans. That workflow > should check whether nb-javac is good enough to build netbeans. Turns > out it is not. which is btw in the wrong repo IMO. CI jobs testing nb-javac would have to be in the nb-javac repo, everything downstream from it is too late. (my opinion didn't change since the PR which introduced the job) > ... > > What I don't get: NB targets JDK 17/21, even our conservative baseline is 8 > versions beyond when `Class#getModule` was introduced. > > ... > > So what to do with this state? Would it make sense to change baseline to > build for the oldest LTS version of Java at a given time? Yes I think we should. Backporting javac to lower JDK versions always assumes that the (sometimes internal) API on JDK 8 level has still the exact same semantics as on 27 - which isn't necessarily the case given such large version range. The bigger the window the higher the probability that something will go wrong. Its like putting a Golf 8 engine into a Golf 1 and hope everything remained compatible as long it still fits. example: https://github.com/apache/netbeans/pull/8572#issuecomment-3041948239 -> https://github.com/JaroslavTulach/nb-javac/pull/31 long story short: I had similar thoughts/worries a while ago and proceeded to check how much of the code transformation could be dropped when targeting newer language levels. I don't update the branches often but here is one which targets JDK 17: e.g: https://github.com/mbien/nb-javac/commits/target-jdk17-3 diff shows how much of the code transformations can be dropped: https://github.com/mbien/nb-javac/compare/50889546cfec421fbfc85158332cede5522d3af2...65135170e1be1dce8f30c7be9d97eb33ecf160f7 A secondary use for it was to build a valhalla version (#8995) which I used for testing editor features. (NB 29 supports the value keyword if the valhalla javac is active) building NB with it does also work (i think!) https://github.com/mbien/nb-javac/actions/runs/23007987014/job/66810163121 I haven't put much time into this though, I might have set a path wrong and it builds with regular javac, but the logs looked good on first glance. Would be good to verify that actual nb-javac is building NB there. Streamlining the nb-javac release process is also something we could consider. Odd NB releases have the javac update at around JDK N build 20 and often a second one later to the shipped version (27-35). The whole process is always a push process. It would be nice if the nb-javac project could be automated so that once updated to a major version, it continues to build/test releases synced with JDK ea builds until GA (or at least more often). NB side can pick the latest version when a release branches. for completeness sake it is also worth pointing out that NB can run without nb-javac if the runtime JDK version matches (int) ((nb + 1) / 2 + 11). Which is not only useful to verify nb-javac specific issues but it could in theory also become an activation requirement for the java cluster if all other efforts to update the NB supply chain fail. best regards, michael > > Greetings > > Matthias > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
