On 4/26/26 17:04, Matthias Bläsing wrote: > Am Donnerstag, dem 23.04.2026 um 00:20 +0200 schrieb Michael Bien: >> On 4/22/26 21:58, Matthias Bläsing wrote: >>> 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) > Such a job exists in nb-javac. But it builds an old NetBeans version, > which in turn masked the problem: > > https://github.com/JaroslavTulach/nb-javac/pull/37 > >>> ... >>> >>> 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 > This reraises the question what is the purpose of nb-javac. If I > counted correctly this halves the patching via jackpot and removes > several no unneeded replacement methods. > > From a maintainability perspective this is quite an improvement. Thanks > for the test! while looking through the diff again I got reminded of another nb-javac issue and filed it as https://github.com/apache/netbeans/issues/9368
so that it isn't lost. 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
