Thanks for clarification jakub
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
