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! 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
