Hello Michael. Thanks to this email I found a PR for an upgrade to jdk-28+23 in my repository: https://github.com/JaroslavTulach/nb-javac/pull/42 The PR has been integrated, bits are released to Maven central and ready for being used at https://repo1.maven.org/maven2/com/dukescript/nbjavac/nb-javac/ jdk-28+23
> I am not proposing to integrate the branch into Jaroslav's repo - the I guess then I cannot do much else than to acknowledge I got your message. > Anyone interested in helping maintain a core component of the NB Java > editor support? Anyone has a right to fork the repository. Anyone can upload the bits to Maven central. I am glad I could play that role in the early days of helping Apache NetBeans to accept nb-javac as a useful component. I'll continue releasing nb-javac at current GAV co-ordinates whenever I notice a PR in my repository: https://github.com/JaroslavTulach/nb-javac -jt > I "bit the bullet" this Sunday when I tried to update editor support to > JDK 28 and rewrote the whole nb-javac build from scratch: > > https://github.com/mbien/nb-javac/tree/bootstrap > > The goal is to make maintenance as easy as possible. In fact I could > iterate on it fairly quickly and was even able to open the JDK 28 editor > update PR the same evening: > > https://github.com/apache/netbeans/pull/9790 > > > so what improved: > > - build is now a Java file. (make would be an option too, gradle > disqualified early + wanted to move away from ant) > - it bootstraps the right way around. It builds upstream JDK and > actually backports the pieces using release=21 > - release 21 makes it trivial to maintain, javac code is basically on > 21 level already. The delta to upstream will also remain constant since > it will move with NB's lower bound > - build is reproducible. Wasn't really intended; was more like a "why > not" moment. Produces checksums right away too - verified by comparing > local with CI. > - no extra dependencies. It compiles with javac, junit for tests (there > is one exception which was deferred to later, see issues). > - significantly reduced Jackport transformation rules > - remains CI friendly. The upstream JDK is cached, build remains at > about 2-3 mins. 15 mins on cache miss. > > drive-by fixes: > > - big one: current nb-javac has ct.sym of JDK 24 in it. This got > automatically fixed by actually building the upstream jdk since that is > where it's from. > - no multi release jar needed (-> less complex setup) > - it is now semantically much closer to upstream javac. As shown in > past builds, just because the code is backported on the API level, > doesn't mean the semantics stayed the same. There is no javac guarantee > that a method on JDK 8 means the exact same as on JDK 28 - it's all > internal code after all. > > > issues i left open since they can wait: > > - it still ships some packages which don't exist anymore in upstream > JDKs (netbeans#9368) > - I don't fully understand why the public API is shipped in two jars > but I didn't want to change too much at once and kept it (although I did > make minor changes, e.g. the api jar leaked javac internals like > LintMapper which is no longer the case) > > It's essentially a somewhat faithful reconstruction of the same layout, > verified by comparing it with prior releases assisted by agents + green > NB CI and a short manual smoke test. > > I am not proposing to integrate the branch into Jaroslav's repo - the > pragmatic choice is probably to change the GAV namespace slightly and > let both coexist; the artifact which shares the lower bound with NB > would be the supply chain artifact for NB. > > Essentially everything technical is solved, I hope. What is left is to > gauge if there is support from other committers who would like to help > maintaining it + doing the first release. > The idea is to sync CI with upstream JDK builds which happen ~bi-weekly > - and upload to central whenever we need a new build. So we can update > twice during an NB release cycle: early and before release. > > Anyone interested in helping maintain a core component of the NB Java > editor support? > > best regards, > > michael > > > Thank you > > > > 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 --------------------------------------------------------------------- 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
