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