You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Jaroslav Tulach <ja...@gmail.com> on 2021/03/07 18:39:21 UTC
Let's learn to love (the new) nb-javac! was: Everybody (else) seems to hate nb-javac!
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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Making sure all nb-javac sources are covered by CPE was: Two
paths to access Javac ASTs
Posted by Neil C Smith <ne...@apache.org>.
On Fri, 2 Apr 2021 at 08:48, Jaroslav Tulach <ja...@gmail.com> wrote:
>
> > OK, looks like we're good to move forward on this if the ambiguity about
> > CPE applying to all sources can be addressed. Over to you!
> >
> > https://issues.apache.org/jira/browse/LEGAL-563
> >
>
> Congratulations Neil! The path to avoid downloading of `nb-javac` after each
> start with an empty user directory is now open!
>
> How do we check all files of `nb-javac` are covered by CPE?
"We" don't! Before you get too congratulatory, the resolution we have
at present is -
"As long as Oracle can provide a clear statement in LICENSE.txt that
nb-javac is licensed under GPL+CPE in its entirety"
It takes the issue of the NetBeans PMC auditing everything out of the
equation entirely at the moment. It leaves us with the need for an
unambiguous clarification in the Oracle nb-javac repository that all
sources (at least those used to create the binary), and any binary
created from that repository, are covered by CPE. Ideally we would
also be using an Oracle distributed binary unambiguously under those
terms. We might be OK with the current binary distribution, and we
might be OK with the clarification being elsewhere than the
LICENSE.txt file, but we need to go back to legal when we know what's
feasible from Oracle side. Hopefully we then have a precedent for
what needs to happen with CPE inclusion in future.
As a matter of fact, is there a full unambiguous list of what sources
and related binaries carry CPE in the whole of OpenJDK somewhere?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Making sure all nb-javac sources are covered by CPE was: Two paths to access Javac ASTs
Posted by Jaroslav Tulach <ja...@gmail.com>.
> OK, looks like we're good to move forward on this if the ambiguity about
> CPE applying to all sources can be addressed. Over to you!
>
> https://issues.apache.org/jira/browse/LEGAL-563
>
Congratulations Neil! The path to avoid downloading of `nb-javac` after each
start with an empty user directory is now open!
How do we check all files of `nb-javac` are covered by CPE? Matthias prepared
the nb-javac source code for [upload of bits to Maven central](https://
github.com/oracle/nb-javac/pull/2) - as part of that a JAR file with sources is
being generated. It can be used to build the whole `nb-javac`. I've just:
```
$ wget https://repo1.maven.org/maven2/com/dukescript/nbjavac/nb-javac/
15.0.0.2/nb-javac-15.0.0.2-sources.jar
$ unzip nb-javac-15.0.0.2-sources.jar
$ JAVA_HOME=/jdk-8/ ant -f ./make/langtools/netbeans/nb-javac/build.xml
```
and got the two `nb-javac*.jar` files as expected. Now, if I instead of
building the sources scan them for CPE and look for
'particular file .* subject to the "Classpath" exception'
as the `LICENSE.md` suggests I get:
```
$ wget https://repo1.maven.org/maven2/com/dukescript/nbjavac/nb-javac/
15.0.0.2/nb-javac-15.0.0.2-sources.jar
$ unzip nb-javac-15.0.0.2-sources.jar
$ rm nb-javac-15.0.0.2-sources.jar
$ find . -type f | while read X; do grep -r 'particular file as subject to the
"Classpath" exception as provided' $X >/dev/null || echo No CPE in $X; done
No CPE in ./SECURITY.md
No CPE in ./LICENSE.txt
No CPE in ./CONTRIBUTING.md
No CPE in ./make/langtools/netbeans/nb-javac/nbproject/project.properties
No CPE in ./make/langtools/netbeans/nb-javac/nbproject/genfiles.properties
No CPE in ./make/langtools/netbeans/nb-javac/nbproject/build-impl.xml
No CPE in ./make/langtools/netbeans/nb-javac/nbproject/project.xml
No CPE in ./make/langtools/netbeans/nb-javac/pom-nb-javac.xml
No CPE in ./make/langtools/netbeans/nb-javac/manifest.mf
No CPE in ./make/langtools/netbeans/nb-javac/test/com/sun/tools/javac/jvm/
Test1.class
No CPE in ./make/langtools/netbeans/nb-javac/test/com/sun/tools/javac/jvm/
V48gen.class
No CPE in ./make/langtools/netbeans/nb-javac/test/com/sun/tools/javac/jvm/
Test2.class
No CPE in ./make/langtools/netbeans/nb-javac/test/com/sun/tools/javac/parser/
DocCommentParserTest.java
No CPE in ./make/langtools/netbeans/nb-javac/build.xml
No CPE in ./README.md
```
Looking at the list of files missing the required sentence, I see none that
becomes part of one of the `nb-javac*.jar` files and could hold such license
text. I conclude that nb-javac-15.0.0.2 as published on Maven central by Toni
is fully covered by Classpath "exception".
-jt
PS: Maybe the license of ./make/langtools/netbeans/nb-javac/pom-nb-javac.xml
could be fixed for next release, right Matthias?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Two paths to access Javac ASTs
Posted by Neil C Smith <ne...@apache.org>.
On Fri, 26 Mar 2021, 12:52 Neil C Smith, <ne...@apache.org> wrote:
> On Fri, 26 Mar 2021 at 09:46, Jaroslav Tulach <ja...@gmail.com>
> wrote:
> > PS: If we could also get LEGAL-563 permission in 13.0 LTS timeframe, that
> > would be magnificent!
>
> I'd like to push, from at least that ticket perspective, to see if
> 12.5 timescale is feasible.
>
> In terms of https://github.com/oracle/nb-javac it would be good to see
> clarification in the readme / license file that *all* sources in that
> repository, and all binaries built from it, are covered by CPE. eg.
> the current wishy-washy-ness of "only where Oracle has expressly
> included in the particular source file's header the words 'Oracle
> designates this particular file as subject to the 'Classpath'
> exception" is a problem.
>
OK, looks like we're good to move forward on this if the ambiguity about
CPE applying to all sources can be addressed. Over to you!
https://issues.apache.org/jira/browse/LEGAL-563
Best wishes,
Neil
Re: Two paths to access Javac ASTs
Posted by Neil C Smith <ne...@apache.org>.
On Fri, 26 Mar 2021 at 09:46, Jaroslav Tulach <ja...@gmail.com> wrote:
> po 22. 3. 2021 v 16:22 odesílatel Neil C Smith <ne...@apache.org>
> napsal:
>
> > On Mon, 22 Mar 2021 at 15:01, Laszlo Kishalmi <la...@gmail.com>
> > wrote:
> > > Is there an NBM available to try this one out?
> >
> > +1! :-)
> >
>
> There is a pull request: https://github.com/apache/netbeans/pull/2801
Not quite an NBM though! Although I presume it may not be feasible to
let people test this on 12.3 anyway?
If / while it remains optional, an NBM would be the preferred route
from a release point of view at least.
> NetBeans IDE 12.5 should require:
> - either run the IDE on JDK17 for Java related development
> - or install modern nbjavac automatically converted with the help of
> [advanced refactorings](https://github.com/oracle/nb-javac/pull/12)
Should that be 12.6 and/or JDK 16? Not sure if it remains optional,
whether requiring an unreleased JDK is a viable position?
Assuming we get permission to distribute nb-javac - what then? Do
both options remain supported?
> PS: If we could also get LEGAL-563 permission in 13.0 LTS timeframe, that
> would be magnificent!
I'd like to push, from at least that ticket perspective, to see if
12.5 timescale is feasible.
In terms of https://github.com/oracle/nb-javac it would be good to see
clarification in the readme / license file that *all* sources in that
repository, and all binaries built from it, are covered by CPE. eg.
the current wishy-washy-ness of "only where Oracle has expressly
included in the particular source file's header the words 'Oracle
designates this particular file as subject to the 'Classpath'
exception" is a problem.
Probably also good if the primary docs were moved to a wiki page on
the repo, and the primary source of help was the issue queue there and
not the mailing lists here, too.
It remains to be seen whether distribution from an Oracle group ID and
explicitly under CPE is a consideration for this.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Two paths to access Javac ASTs
Posted by Jaroslav Tulach <ja...@gmail.com>.
po 22. 3. 2021 v 16:22 odesílatel Neil C Smith <ne...@apache.org>
napsal:
> On Mon, 22 Mar 2021 at 15:01, Laszlo Kishalmi <la...@gmail.com>
> wrote:
> > Is there an NBM available to try this one out?
>
> +1! :-)
>
There is a pull request: https://github.com/apache/netbeans/pull/2801 - I
am trying to help with it as much as I can and provide some guidance. There
is however still tons of failures mostly because nb-javac and upstream
javac are:
- treated differently
- tested differently
- known to behave differently
- known to be differently buggy
We are wasting time maintaining two different lines of code and none of
them works well! All of that makes me more and more convinced: It is really
essential for the Apache NetBeans project to stop using the manually
crafted NbJavac as soon as 12.4 is out!
NetBeans IDE 12.5 should require:
- either run the IDE on JDK17 for Java related development
- or install modern nbjavac automatically converted with the help of
[advanced refactorings](https://github.com/oracle/nb-javac/pull/12)
E.g. implement the plan as outlined at
https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac
> Telling the truth the javac integration in 12.3 became really unstable,
> ...
> We have lots of issues reported on them in JIRA as well.
In my opinion, throwing away the "two paths to (parse and) access Javac
ASTs" is going to help us improving the quality. It will finally be clear
that "Javac from the latest JDK" is the reference implementation of
NetBeans IDE "parser" that we have to optimize for, bugfix for and develop
against.
-jt
PS: If we could also get LEGAL-563 permission in 13.0 LTS timeframe, that
would be magnificent!
Re: Two paths to access Javac ASTs
Posted by Neil C Smith <ne...@apache.org>.
On Mon, 22 Mar 2021 at 15:01, Laszlo Kishalmi <la...@gmail.com> wrote:
> Is there an NBM available to try this one out?
+1! :-)
> Telling the truth the javac integration in 12.3 became really unstable,
> either with standard JDK 15 or nb-javac. I'm trying to go back to JDK11
> as runtime and trying my luck with different compilers, but we have
> NPE-s, IllegalStateExceptions flying out from the parser every now and
> then. We have lots of issues reported on them in JIRA as well.
I'm not sure if it's any worse than 12.2. I've noticed this a lot
with both. Did much change in this area between anyway? Sometimes
getting rid of the cache fixed things for a bit. Seems generally to
be getting less stable since 12.0.
Yes, lots of JIRA tickets here - possibly an area of focus for 12.4 testing?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Two paths to access Javac ASTs
Posted by Laszlo Kishalmi <la...@gmail.com>.
Is there an NBM available to try this one out?
Telling the truth the javac integration in 12.3 became really unstable,
either with standard JDK 15 or nb-javac. I'm trying to go back to JDK11
as runtime and trying my luck with different compilers, but we have
NPE-s, IllegalStateExceptions flying out from the parser every now and
then. We have lots of issues reported on them in JIRA as well.
On 3/10/21 10:48 PM, Jaroslav Tulach wrote:
>> 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
>>
>> <ja...@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
>>>>
>>>> <ja...@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
>>>>>>
>>>>>> <ja...@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-unsubscribe@netbeans.apache.org
>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Two paths to access Javac ASTs
Posted by Jaroslav Tulach <ja...@gmail.com>.
> 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
>
> <ja...@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
> >>
> >> <ja...@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
> >> > >
> >> > > <ja...@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-unsubscribe@netbeans.apache.org
> >> > > > For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> >> > > For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Two paths to access Javac ASTs was: Access to Tag.getSummary()
Posted by Jakub Herkel <jh...@gmail.com>.
Thanks for clarification
jakub
On Tue, Mar 9, 2021 at 11:46 AM Jaroslav Tulach
<ja...@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
>> <ja...@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
>> > >
>> > > <ja...@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-unsubscribe@netbeans.apache.org
>> > > > For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
>> > > For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Two paths to access Javac ASTs was: Access to Tag.getSummary()
Posted by Jaroslav Tulach <ja...@gmail.com>.
>
> 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
> <ja...@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
> > >
> > > <ja...@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-unsubscribe@netbeans.apache.org
> > > > For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> > > For additional commands, e-mail: dev-help@netbeans.apache.org
> > >
> > > For further information about the NetBeans mailing lists, visit:
> > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>
Access to Tag.getSummary() was: Let's learn to love (the new) nb-javac!
Posted by Jaroslav Tulach <ja...@gmail.com>.
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
>
> <ja...@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-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Let's learn to love (the new) nb-javac! was: Everybody (else)
seems to hate nb-javac!
Posted by Jakub Herkel <jh...@gmail.com>.
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
<ja...@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Let's learn to love (the new) nb-javac!
Posted by Neil C Smith <ne...@apache.org>.
Hi,
Couple of comments inline - firstly, have opened
https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-563
Hopefully OK?
It's not like it's asking any more than
https://issues.apache.org/jira/browse/LEGAL-489 mind you, but
hopefully updated info might help! :-\
On Thu, 11 Mar 2021 at 07:45, Jaroslav Tulach <ja...@gmail.com> wrote:
> It always depends how one tells the story. I want to find arguments for Apache
> NetBeans to bundle `nb-javac` along with the convenience binaries. When I say
> "the only purpose" I want to stress that the maintainers of `nb-javac` really
> want it to be used that way.
True! And as maintainers that makes sense. From the ASF / NetBeans
as consumer angle, IMO it's a positive if it's a library that has
other users than just us. And the "entirely separate from our
products" argument is a little easier.
> > And
> > published via Oracle namespace in future?
>
> I am quite happy with current setup where Toni uploads the binaries to Maven
> central. I have no intention to change it[1].
Given that one concern (from legal) is ensuring CPE applies, eg. that
all source files used to create the resulting binary are subject to
CPE, it *might* be easier if the binary we consume was built by and
from *a* namespace belonging to the copyright holder, and with
explicit CPE license attached. Let's see what we get back.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Let's learn to love (the new) nb-javac!
Posted by Jaroslav Tulach <ja...@gmail.com>.
Hello Neil.
> > Right. `nb-javac` is an independent component created with only purpose:
> > To be consumed by (Apache) NetBeans project ..
>
> Well, to me the "only purpose" bit is the crux of the "independent"
> argument, and makes it rather different to other libraries we use, but
> also from plugins. I'm not sure it's necessarily useful to say that
> it continues to be developed with only that purpose?
It always depends how one tells the story. I want to find arguments for Apache
NetBeans to bundle `nb-javac` along with the convenience binaries. When I say
"the only purpose" I want to stress that the maintainers of `nb-javac` really
want it to be used that way.
> The other things obviously are independent public source hosting and
> build instructions, independent distribution, independent issue
> tracking, etc. All things I think have been addressed recently.
Right. All of that is in place at https://github.com/oracle/nb-javac and with
the help of Toni Epple the JARs are even distributed via Maven central.
> > In Dec/Nov 2020 I made a commitment (internally in Oracle) to take over
> > the maintenance of `nb-javac`.
>
> As in maintained and developed by Oracle Labs into the future?
Yes, I am involved and I plan to be involved. With https://github.com/oracle/
nb-javac/pull/12 the maintenance is trivial. As such I am not afraid to commit
to continue maintaining the `nb-javac` in the future.
I also believe that, once we settle on unified infrastructure to use the same
Javac libraries (either from latest JDK or via nb-javac backport), OracleLabs
will be able to improve the user experience (completion, hints, project
integration, debugging experience) even more than we have done during last two
releases.
> And
> published via Oracle namespace in future?
I am quite happy with current setup where Toni uploads the binaries to Maven
central. I have no intention to change it[1].
> Because ...
> OK, I'm inclined to open a legal ticket then, and see where we get
> with that so we can at least plan based on it. Any objections? Or
> someone else really want to do it?
> I think with the recent assessment that CPE *could* be compatible with
> ASF licensing requirements, we're left with also ensuring it's all
> fully independent - sources moved from legacy netbeans.org location to
> Oracle namespace, binaries no longer consumed from OSUOSL - I think
> we're in a much better place there now.
It would be amazing to see the automatically generated `nb-javac` based on
JDK-17 `javac` to be included in NetBeans convenience binaries!
-jt
[1] Please note that neither GraalVM libraries are uploaded to Maven under
Oracle namespace. For example:
https://search.maven.org/search?q=g:org.graalvm.tools
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: LSP - eating our own dog food was: Let's learn to love (the new) nb-javac!
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 11 Mar 2021 at 08:08, Jaroslav Tulach <ja...@gmail.com> wrote:
> Looks like the invention of LSP was really great move by the VSCode guys! It
> allows each language to provide good enough IDE support by coding in the
> language itself and writing the "server side" IDE piece while reusing
> internals of own language compiler. No surprise everyone is providing LSP
> servers.
Agreed!
> > I remember
> > talking with you at JCrete on this during early transition, and about
> > the fact that the other, other VSCode LSP support was using it.
>
> The days where NetBeans could afford to support any language on the planet are
> over. There is just a few of us and we don't have the momentum we used to have
> in the first ten years of this century. In such situation re-using work done by
> others via LSP is the best option we have.
In the bit you quoted I was meaning other consumers of nb-javac ...
But in general, I think us embracing LSP as a server provider, and as
a consumer for other languages is great. But I'm trying to ask
whether we should be moving towards a position where *every* language
in the IDE UI is supported by an LSP server, ours or someone else's?
A *long term* goal to consume our own Java LSP server might, with
limited resources, link ...
> VSCode support is
> important for OracleLabs strategy, it actually means quite a lot of
> contributions from Sváťa, Dušan, Martin, me.
... even more into the IDE experience?
I also mentioned re. nb-javac because the alternative if we can't rely
on nb-javac as the single option in future to support developing JDK
19 while running on JDK 17 is surely along the lines of ..
https://github.com/apache/netbeans/pull/1475
?
> > don't think it still is, maybe it could be encouraged back to it - an
> > independent component that provides useful features for editors in
> > general, and is consumed by other projects, is a good thing IMO!
>
> PS: Such an independent component would have to be built on top of `(nb)-
> javac`. I don't understand how that would simplify the licensing or
> distribution? As far as I can tell all the problems we are solving now would
> remain the same.
Again, it won't, because that bit was specifically talking about other
consumers of nb-javac.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
LSP - eating our own dog food was: Let's learn to love (the new) nb-javac!
Posted by Jaroslav Tulach <ja...@gmail.com>.
Let's open another thread...
> > > Could that also be
> > > addressed by eating our own dog food and running the LSP on the target
> > > VM?
> >
> > That is an unexplored area for me. I assume it is a long road to get there
> > and keep the current level of Java support.
>
> Almost certainly. OTOH there seems to be a lot more focus on LSP at
> the moment, so I wondered whether it's a useful direction of travel
> that actually focuses efforts and longer-term reduces workload? Just
> throwing it out there - I like the idea of decoupling into UI and
> headless processes anyway, potentially running on different VMs. A
> thread for another day!
Looks like the invention of LSP was really great move by the VSCode guys! It
allows each language to provide good enough IDE support by coding in the
language itself and writing the "server side" IDE piece while reusing
internals of own language compiler. No surprise everyone is providing LSP
servers.
> I remember
> talking with you at JCrete on this during early transition, and about
> the fact that the other, other VSCode LSP support was using it.
The days where NetBeans could afford to support any language on the planet are
over. There is just a few of us and we don't have the momentum we used to have
in the first ten years of this century. In such situation re-using work done by
others via LSP is the best option we have.
It took me a long time to convince Jan Lahoda to bet on LSP, but the results
are great! I am really enjoying editing TypeScript in NetBeans these days and
that's all possible only because of yet adopting LSP and creating
infrastructure to use such servers.
From the other side (again thanks to Jan's early work) we can use the NetBeans
infrastructure and expose it (via LSP) to VSCode users. As VSCode support is
important for OracleLabs strategy, it actually means quite a lot of
contributions from Sváťa, Dušan, Martin, me. As there is close synergy between
VSNetBeans and real NetBeans, the whole project benefits.
All of that has only been possible thanks to relying on LSP. Amazing result,
I'd say.
-jt
> I
> don't think it still is, maybe it could be encouraged back to it - an
> independent component that provides useful features for editors in
> general, and is consumed by other projects, is a good thing IMO!
PS: Such an independent component would have to be built on top of `(nb)-
javac`. I don't understand how that would simplify the licensing or
distribution? As far as I can tell all the problems we are solving now would
remain the same.
PPS: Running `ant -f java/java.lsp.server/ build-lsp-server` actually creates
such component.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Let's learn to love (the new) nb-javac!
Posted by Neil C Smith <ne...@apache.org>.
Hi,
Thanks for the detailed response! A few comments inline - let's see
how we get this to the next stage then ...
On Tue, 9 Mar 2021 at 12:01, Jaroslav Tulach <ja...@gmail.com> wrote:
> Right. `nb-javac` is an independent component created with only purpose: To
> be consumed by (Apache) NetBeans project ..
Well, to me the "only purpose" bit is the crux of the "independent"
argument, and makes it rather different to other libraries we use, but
also from plugins. I'm not sure it's necessarily useful to say that
it continues to be developed with only that purpose? I remember
talking with you at JCrete on this during early transition, and about
the fact that the other, other VSCode LSP support was using it. I
don't think it still is, maybe it could be encouraged back to it - an
independent component that provides useful features for editors in
general, and is consumed by other projects, is a good thing IMO!
The other things obviously are independent public source hosting and
build instructions, independent distribution, independent issue
tracking, etc. All things I think have been addressed recently.
> The previous delays were caused by the need to do manual changes and that
> is being eliminated by https://github.com/oracle/nb-javac/pull/12.
Partly, yes. Although a lot has also been to do with delays in
integration and our infrastructure. eg. switch to third-party UC in
11.2 was caused by inability of plugin portal to handle different IDE
releases (something we unfortunately still have), and current delay
was caused by conflation of bug fixes with switch to Maven.
The nb-javac team have done a great job - I think partly it's also,
from a previous schedule thread, that our release schedule and that of
the JDK make timing a little awkward?
> In Dec/Nov 2020 I made a commitment (internally in Oracle) to take over the
> maintenance of `nb-javac`.
As in maintained and developed by Oracle Labs into the future? And
published via Oracle namespace in future? Because ...
> > go back to Apache Legal and request permission to ship nb-javac as a
> > dependency out of the box. Is that actually a desirable outcome,
> > particularly considering above?
>
> +100, yes, that's the desirable outcome.
OK, I'm inclined to open a legal ticket then, and see where we get
with that so we can at least plan based on it. Any objections? Or
someone else really want to do it?
I think with the recent assessment that CPE *could* be compatible with
ASF licensing requirements, we're left with also ensuring it's all
fully independent - sources moved from legacy netbeans.org location to
Oracle namespace, binaries no longer consumed from OSUOSL - I think
we're in a much better place there now.
> That means `nb-javac` ...
> ...is an optional dependency.
I still think we're playing semantics a little there with what
"optional" means, and I think it sometimes colours decisions about
this. The other part of that ASF quote was about not being used by
the majority of users, and I think that's a harder one to claim.
OTOH, we were also allowed to do what we're currently doing because
the need to accept GPL+CPE is hardly a surprise to someone wanting to
develop in Java.
There is the question whether, in either scenario, nb-javac should be
a non-optional requirement for opting in to Java development?
> > Could that also be
> > addressed by eating our own dog food and running the LSP on the target
> > VM?
>
> That is an unexplored area for me. I assume it is a long road to get there
> and keep the current level of Java support.
Almost certainly. OTOH there seems to be a lot more focus on LSP at
the moment, so I wondered whether it's a useful direction of travel
that actually focuses efforts and longer-term reduces workload? Just
throwing it out there - I like the idea of decoupling into UI and
headless processes anyway, potentially running on different VMs. A
thread for another day!
> Choices are always tough. Luckily for me, I don't have a choice. I promised
> to take away the cost of maintenance from current `nb-javac` maintainers by
> end of 2021. On the other side I need NetBeans IDE and/or VSNetBeans to run
> on GraalVM8. I am doing my best to balance these two requirements.
Awesome! Choice made then ... well, partly. :-)
Thanks and best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Let's learn to love (the new) nb-javac!
Posted by Jaroslav Tulach <ja...@gmail.com>.
>
> > https://github.com/oracle/nb-javac/pull/12
> >
> > Manually written nb-javac is dead. Long live the new nb-javac!
>
> Firstly, let me say I think that's a great move forward for nb-javac.
> And from how I worded that, you probably know I'm going to raise a
> "however" .. :-) Not something that might be a showstopper to us
> learning to love nb-javac though ..
>
> > > Let's develop the new `nb-javac` and let's learn to love it!
>
> We need to unpick that sentence into two parts. If we presume "Let's
> develop" means Let *us* develop, then the simple answer is we can't.
> Development of nb-javac has to be external and independent.
Right. `nb-javac` is an independent component created with only purpose: To
be consumed by (Apache) NetBeans project and help to improve experience of
NetBeans Java IDE users.
> At the
> same time, in my experience from release managing, nb-javac has been
> the number one cause of release delays. Somehow those things need to
> be reconciled. In order to love nb-javac, surely we would need a long
> term, external commitment to develop it, and a surety that the
> external project can meet our release requirements?
The work on [automatic refactoring of JDK's javac to nb-javac](
https://github.com/oracle/nb-javac/pull/12) shall improve the situation.
Just change the JDK's commit to import, run the build, upload the binaries.
The previous delays were caused by the need to do manual changes and that
is being eliminated by https://github.com/oracle/nb-javac/pull/12.
> And I realise
> that "external" there is probably going to be mostly if not
> exclusively run by people who also happen to be NetBeans committers or
> PMC, just not here!
>
In Dec/Nov 2020 I made a commitment (internally in Oracle) to take over the
maintenance of `nb-javac`. The plan
https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac
and the work in https://github.com/oracle/nb-javac/pull/12 are results of
that promise. Btw. the plan mentions JDK17 as the target date - e.g. I
assume it is going to take quite some time, before the ownership of
`nb-javac` is transferred to me. Certainly I can't provide any estimate
neither whether that happens at the end or not.
> Assuming that, then can we learn to love it? Well, firstly, as you're
> looking at the sources, an audit that every file is really subject to
> CPE *may* actually allow, given more recent developments, us to go
> back to Apache Legal and request permission to ship nb-javac as a
> dependency out of the box. Is that actually a desirable outcome,
> particularly considering above?
>
+100, yes, that's the desirable outcome. Jakub Herkel has just complained
about two different ways to use javac in NetBeans - having just one (e.g.
automatically generated `nb-javac` from the latest JDK) would be awesome!
If it remains an optional dependency,
Javac is hard dependency for NetBeans Java IDE (not for PHP, JavaScript
parts, etc.) right now. Luckily it comes as a system dependency (from any
modern JDK). That means `nb-javac` is ...
> then we're left with considering
> "Optional means that the component is not required for standard use of
> the product or for the product to achieve a desirable level of
> quality.
...is an optional dependency. People can use NetBeans on latest JDK and get
the same (with https://github.com/oracle/nb-javac/pull/12 it is really the
same!) experience. Given JDK17 is going to be an LTS I'd suggest to force
NetBeans IDE users to: Either run NetBeans on JDK17 or install nb-javac!
> What about editing JDK 19 while running on JDK 17?
That would only be possible with `nbjavac@19` running on JDK 17.
> Could that also be
> addressed by eating our own dog food and running the LSP on the target
> VM?
That is an unexplored area for me. I assume it is a long road to get there
and keep the current level of Java support. Certainly longer than my
nb-javac plans:
https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac
> The key thing being, if nb-javac remains optional, then what
> features of the IDE do we continue to consider non-standard or not
> wanted by the majority of users?
>
I believe it is the combination of IDE's JDK/Java features that creates the
restrictions. Without `nb-javac` selecting the right JDK matters. With
`nb-javac` and any JDK8+ one can run NetBeans IDE and use the latest Java
features without any restrictions.
> Contrary to the assertion, I'm not sure that everyone hates nb-javac.
> I don't! I think we've been staring at a map for a good long while,
> may have finally reached the fork in the road that we could see on the
> horizon, and are still not quite sure which direction to take.
>
Choices are always tough. Luckily for me, I don't have a choice. I promised
to take away the cost of maintenance from current `nb-javac` maintainers by
end of 2021. On the other side I need NetBeans IDE and/or VSNetBeans to run
on GraalVM8. I am doing my best to balance these two requirements.
-jt
Re: Let's learn to love (the new) nb-javac! was: Everybody (else)
seems to hate nb-javac!
Posted by Neil C Smith <ne...@apache.org>.
Hi,
On Sun, 7 Mar 2021 at 18:39, Jaroslav Tulach <ja...@gmail.com> wrote:
> 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!
Firstly, let me say I think that's a great move forward for nb-javac.
And from how I worded that, you probably know I'm going to raise a
"however" .. :-) Not something that might be a showstopper to us
learning to love nb-javac though ..
> > Let's develop the new `nb-javac` and let's learn to love it!
We need to unpick that sentence into two parts. If we presume "Let's
develop" means Let *us* develop, then the simple answer is we can't.
Development of nb-javac has to be external and independent. At the
same time, in my experience from release managing, nb-javac has been
the number one cause of release delays. Somehow those things need to
be reconciled. In order to love nb-javac, surely we would need a long
term, external commitment to develop it, and a surety that the
external project can meet our release requirements? And I realise
that "external" there is probably going to be mostly if not
exclusively run by people who also happen to be NetBeans committers or
PMC, just not here!
Assuming that, then can we learn to love it? Well, firstly, as you're
looking at the sources, an audit that every file is really subject to
CPE *may* actually allow, given more recent developments, us to go
back to Apache Legal and request permission to ship nb-javac as a
dependency out of the box. Is that actually a desirable outcome,
particularly considering above?
If it remains an optional dependency, then we're left with considering
"Optional means that the component is not required for standard use of
the product or for the product to achieve a desirable level of
quality. The question to ask yourself in this situation is: Will the
majority of users want to use my product without adding the optional
components?" Beyond JDK 17 do we consider compile on save a niche
feature? Well, I'd like a global switch for it, so maybe! :-) What
about editing JDK 19 while running on JDK 17? Could that also be
addressed by eating our own dog food and running the LSP on the target
VM? The key thing being, if nb-javac remains optional, then what
features of the IDE do we continue to consider non-standard or not
wanted by the majority of users?
Contrary to the assertion, I'm not sure that everyone hates nb-javac.
I don't! I think we've been staring at a map for a good long while,
may have finally reached the fork in the road that we could see on the
horizon, and are still not quite sure which direction to take.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists