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
