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
