> Thanks for clarification Btw. I've just noticed an effort to integrate the automatically generated nb- javac@16 into NetBeans: https://github.com/apache/netbeans/pull/2801 One thing I find really amusing is the removal of the whole `java/ java.source.nbjavac` module. More than three thousand of lines deleted!
That, in my opinion, means that by adopting the automatic processing of nb- javac we are closing the gap between the "two paths" that NetBeans currently have to maintain. -jt PS: In the "Let's learn to love (the new) nb-javac!" thread Neil indicated that the recent ASF policy may be in favor of including nb-javac into NetBeans convenience binaries. It would be amazing if that happened! Then the "two paths" would join into one. > On Tue, Mar 9, 2021 at 11:46 AM Jaroslav Tulach > > <jaroslav.tul...@gmail.com> wrote: > >> Well it means there still will be a possibility to choose from two > >> > >> paths? > > > > `nb-javac` is licensed as GPLv2 with Classpath Exception - ASF doesn't > > like to distribute GPLv2 software. Apache software shall not have a > > non-avoidable non-system dependency on GPL software. Luckily there is > > `javac` in the JDK (where JDK is considered a system dependency) and > > NetBeans can use it. Alas, that implies two paths: - use latest JDK with > > its javac > > - use older JDK and nbjavac > > > > At least that's the current situation. My work on automatic backporting of > > `nbjavac` doesn't try to change the current setup. It just makes the > > differences between latest JDK `javac` and latest `nb-javac` as small as > > possible. > > > > Best regards. > > -jt > > > >> One with the new nb-javac and the second with a javac from JDK > >> installation? My thinking about new nb-javac was like: > >> we will always install nb-javac and independently from current JDK we > >> will be able to parse the latest language features (depends on version > >> of nb-javac). > >> Because from my point of view if we internally depend on > >> com.sun.source and there is a difference between what we can use > >> during compilation of netbeans sources and what we get during parsing > >> there still will be a "problem" for implemention of new language > >> features. I think there could be a parity between > >> > >> parser and abstract syntax tree. So if our parser for example for > >> > >> netbeans 14 is able to parse java sources for Java 17 we can also use > >> this AST in sources. Without any introspection (like in my code). I > >> know maybe I'm looking too far but is there a plan how to solve this? > >> > >> Jakub > >> > >> On Mon, Mar 8, 2021 at 11:44 AM Jaroslav Tulach > >> > >> <jaroslav.tul...@gmail.com> wrote: > >> > Hello Jakub. > >> > Your inquiry isn't really related to "new vs. old" `nbjavac` as far as > >> > I can tell, but to what API we compile against. Please see > >> > > >> > https://github.com/apache/netbeans/pull/2783 > >> > > >> > If that PR got accepted, then (I believe) the new "summary" > >> > class/method > >> > would be available in the API for you to compile against. That's the > >> > pro. On the cons side, the change proposed in #2783 would very likely > >> > mean NetBeans Java support would require `nbjavac` on any JDK<15. I am > >> > not sure our project is ready to make such switch. > >> > > >> > Best regards. > >> > -jt > >> > > >> > Dne pondělí 8. března 2021 10:44:49 CET, Jakub Herkel napsal(a): > >> > > I would like to clarify one thing for me. If I understand correctly > >> > > with this new nb-javac we will have only one parser for java sources. > >> > > That is superb news (I have had/have lot of problems with parsing, > >> > > exceptions,...) > >> > > but I still see another problem here (but maybe I missed something) : > >> > > When I tried to fix some issues I had to write some ugly code > >> > > (NETBEANS-1309): switch(tag.getKind().name()) { > >> > > > >> > > case "SUMMARY" : > >> > > try { > >> > > > >> > > Method getSummaryMethod = > >> > > > >> > > tag.getClass().getDeclaredMethod("getSummary"); > >> > > > >> > > List<? extends DocTree> summaryList = > >> > > > >> > > (List<? extends DocTree>)getSummaryMethod.invoke(tag); > >> > > > >> > > sb.append(inlineTags(summaryList, > >> > > > >> > > docPath, doc, trees, null)); > >> > > > >> > > } catch(NoSuchMethodException | > >> > > > >> > > SecurityException | IllegalAccessException | IllegalArgumentException > >> > > > >> > > | InvocationTargetException ex) { > >> > > | > >> > > // IGNORE > >> > > > >> > > } > >> > > break; > >> > > > >> > > Problem here is that code in the netbeans depends on > >> > > com.sun.source.doctree.* classes. But because we need to compile also > >> > > with JDK8 we don't have access to new features (for this fix a new > >> > > @Summary tag). Could this new nb-javac also help us > >> > > with type of "hack"? > >> > > > >> > > jakub > >> > > > >> > > On Sun, Mar 7, 2021 at 7:39 PM Jaroslav Tulach > >> > > > >> > > <jaroslav.tul...@gmail.com> wrote: > >> > > > Hi. > >> > > > After enumerating the `nb-javac` deficiencies (below) and writing a > >> > > > plan > >> > > > to > >> > > > address them at our wiki > >> > > > https://cwiki.apache.org/confluence/display/NETBEANS/ > >> > > > Overview%3A+nb-javac I am here with implementation of the automatic > >> > > > conversion of JDK16(!, yes we are half a year ahead the plan!) > >> > > > `javac`. > >> > > > Please join me in reviewing and discussing the consequences for > >> > > > NetBeans > >> > > > here or in the PR#12: > >> > > > > >> > > > https://github.com/oracle/nb-javac/pull/12 > >> > > > > >> > > > Manually written nb-javac is dead. Long live the new nb-javac! > >> > > > -jt > >> > > > > >> > > > On Dec 18, 2020 [I wrote](https://lists.apache.org/thread.html/ > >> > > >> > r5f210c99b0926aeaac2d0c3c419ff4b79e01f15b67c5ddcf32a51bbe%40%3Cdev.netbeans.apache.org%3E): > >> > > > > Hi. > >> > > > > First and foremost. I admire the work Arvind & his team are doing > >> > > > > while > >> > > > > maintaining [nb-javac](http://github.com/oracle/nb-javac). I am > >> > > > > sure > >> > > > > they > >> > > > > don't hate it. Neither do I, but let's talk about the rest of us > >> > > > > who > >> > > > > have > >> > > > > some concerns... > >> > > > > > >> > > > > > Our love and hate relationship to nb-javac needs to be > >> > > > > > resolved. We > >> > > > > > suggest people to go without it, then we suggest people to try > >> > > > > > that. > >> > > > > > Also with the current release we see an increased amount of > >> > > > > > NPE-s and > >> > > > > > parsing errors. > >> > > > > > > >> > > > > > > >> > > > > > Two directions of thinking: > >> > > > > > 2. we need to get rid of nb-javac. > >> > > > > > #2 is a long term (~ a year) thing. I've been discussing > >> > > > > > possible ways > >> > > > > > to implement #2 and I think it can be done, > >> > > > > > if JDK's javac is improved with currently missing IDE-friently > >> > > > > > >> > > > > capabilities. > >> > > > > > >> > > > > > More on that in a separate email later. > >> > > > > > >> > > > > OK, this is the email. Let's enumerate the "haters": > >> > > > > > >> > > > > - Apache doesn't like `nb-javac` as it is GPLv2+CPEx component > >> > > > > and those > >> > > > > are hard to distribute > >> > > > > > >> > > > > - it would be way easier to use plain `javac` from a JDK > >> > > > > - distribution is problematic - needs internet connection and > >> > > > > nb-javac > >> > > > > > >> > > > > isn't yet on Maven central > >> > > > > - testers hate `nb-javac` as it multiplies the matrix of things > >> > > > > to test > >> > > > > > >> > > > > - each JDK needs to be tested twice - with `nb-javac` and > >> > > > > without > >> > > > > > >> > > > > `nb-javac` > >> > > > > > >> > > > > - with every bug/problem one needs to know whether `nb-javac` > >> > > > > was or > >> > > > > > >> > > > > wasn't in use > >> > > > > > >> > > > > - recent version `nb-javac-15` isn't really stable, see > >> > > > > complains on > >> > > > > the > >> > > > > > >> > > > > mailing list > >> > > > > - maintainers of JDK's `javac` hate `nb-javac` because it is a > >> > > > > fork of > >> > > > > their own work > >> > > > > > >> > > > > - nobody likes forks > >> > > > > - ironically Arvind's team is part of JDK organization - e.g. > >> > > > > it > >> > > > > > >> > > > > maintains own fork of JDK's `javac` > >> > > > > > >> > > > > Clearly there are numerous drawbacks and we need a way out. Let's > >> > > > > get > >> > > > > rid > >> > > > > of `nb-javac` as we know it. Let's replace it with JDK's own > >> > > > > `javac`! > >> > > > > Great, right? But there are problems... > >> > > > > > >> > > > > - `javac` in JDK15 isn't good enough > >> > > > > > >> > > > > - compile on save doesn't work > >> > > > > - re-compilation of a single method doesn't work > >> > > > > - runs out of memory more often than `nb-javac`. > >> > > > > > >> > > > > Before we can get rid of `nb-javac`, we need to be sure `javac` > >> > > > > in JDK > >> > > > > is > >> > > > > good enough. I let Jan Lahoda (a JDK engineer working on `javac`) > >> > > > > comment > >> > > > > and solve(!) this somehow. Let's now assume JDK17 offers good > >> > > > > enough > >> > > > > `javac`, now we: > >> > > > > > >> > > > > - suggest people to use JDK17 when using Apache NetBeans IDE > >> > > > > > >> > > > > - not a big problem, JDK17 is LTS, but then? > >> > > > > - if people wanted to use language features of JDK19, they'd > >> > > > > have to > >> > > > > run > >> > > > > > >> > > > > on 19! > >> > > > > > >> > > > > - that's not what competition does - they support latest > >> > > > > language > >> > > > > > >> > > > > features running on JDK11 LTS or even JDK8 LTS > >> > > > > > >> > > > > The story may end here and it can be a good enough story for > >> > > > > Apache > >> > > > > NetBeans IDE. However, I don't like it. It is not good enough > >> > > > > story yet. > >> > > > > I > >> > > > > & OracleLabs want to run on LTS and support the latest Java > >> > > > > features. As > >> > > > > such I am ready to make sure JDK17's `javac` runs on JDK8. Can > >> > > > > anything > >> > > > > stop me? > >> > > > > > >> > > > > - latest `javac` is written in the language syntax of modern Java > >> > > > > > >> > > > > - such syntax cannot be compiled to JDK8 bytecode with `javac` > >> > > > > > >> > > > > - latest `javac` is using APIs not available on JDK8 > >> > > > > > >> > > > > - one needs to rewrite these calls to some older APIs > >> > > > > - the behavior needs to be tested to remain the same > >> > > > > > >> > > > > The great revelation is that both these problems can be solved > >> > > > > with > >> > > > > [Jackpot](https://netbeans.apache.org/jackpot/index.html)! Rather > >> > > > > than > >> > > > > maintaining manual patches like `nb-javac` does, let's write > >> > > > > Jackpot > >> > > > > rules > >> > > > > and apply them automatically. For example `Optional.isEmpty()` > >> > > > > method > >> > > > > has > >> > > > > been added in JDK11. Let's add following rule: > >> > > > > > >> > > > > ```jackpot > >> > > > > $1.isEmpty() :: $1 instanceof java.util.Optional > >> > > > > => > >> > > > > !$1.isPresent() > >> > > > > ;; > >> > > > > ``` > >> > > > > > >> > > > > That automatically rewrites all occurences of > >> > > > > `optional.isEmpty()` to > >> > > > > `!optional.isPresent()` and that is going to compile on JDK8. Few > >> > > > > more > >> > > > > (~30) rules like this and the `javac` is almost ready to run on > >> > > > > JDK8! > >> > > > > Then > >> > > > > we need to run some tests to verify the behavior is same as of > >> > > > > JDK's > >> > > > > `javac` and then we'll be where I want us to be: > >> > > > > > >> > > > > People can use Apache NetBeans with `javac` from the latest JDK > >> > > > > or they > >> > > > > can > >> > > > > use the automatic port of the same code running on JDK8. Ideally > >> > > > > the > >> > > > > behavior shall be identical. No more questions: Are you using > >> > > > > nb-javac > >> > > > > or > >> > > > > not? No more duplicated testing matrix. > >> > > > > > >> > > > > Moreover vendors of applications built on top of NetBeans can > >> > > > > decide > >> > > > > whether they include `nb-javac` port or not. OracleLabs will > >> > > > > include it > >> > > > > as > >> > > > > we really want our tools to run on GraalVM based on JDK8 and > >> > > > > still > >> > > > > support > >> > > > > the latest Java features. > >> > > > > > >> > > > > Let's develop the new `nb-javac` and let's learn to love it! > >> > > > > -jt > >> > > > > >> > > > ------------------------------------------------------------------- > >> > > > -- > >> > > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > >> > > > For additional commands, e-mail: dev-h...@netbeans.apache.org > >> > > > > >> > > > For further information about the NetBeans mailing lists, visit: > >> > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > >> > > > >> > > --------------------------------------------------------------------- > >> > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > >> > > For additional commands, e-mail: dev-h...@netbeans.apache.org > >> > > > >> > > For further information about the NetBeans mailing lists, visit: > >> > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
