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
<jaroslav.tul...@gmail.com> wrote:
Well it means there still will be a possibility to choose from two
paths?
`nb-javac` is licensed as GPLv2 with Classpath Exception - ASF doesn't
like to distribute GPLv2 software. Apache software shall not have a
non-avoidable non-system dependency on GPL software. Luckily there is
`javac` in the JDK (where JDK is considered a system dependency) and
NetBeans can use it. Alas, that implies two paths: - use latest JDK with
its javac
- use older JDK and nbjavac
At least that's the current situation. My work on automatic backporting of
`nbjavac` doesn't try to change the current setup. It just makes the
differences between latest JDK `javac` and latest `nb-javac` as small as
possible.
Best regards.
-jt
One with the new nb-javac and the second with a javac from JDK
installation? My thinking about new nb-javac was like:
we will always install nb-javac and independently from current JDK we
will be able to parse the latest language features (depends on version
of nb-javac).
Because from my point of view if we internally depend on
com.sun.source and there is a difference between what we can use
during compilation of netbeans sources and what we get during parsing
there still will be a "problem" for implemention of new language
features. I think there could be a parity between
parser and abstract syntax tree. So if our parser for example for
netbeans 14 is able to parse java sources for Java 17 we can also use
this AST in sources. Without any introspection (like in my code). I
know maybe I'm looking too far but is there a plan how to solve this?
Jakub
On Mon, Mar 8, 2021 at 11:44 AM Jaroslav Tulach
<jaroslav.tul...@gmail.com> wrote:
Hello Jakub.
Your inquiry isn't really related to "new vs. old" `nbjavac` as far as
I can tell, but to what API we compile against. Please see
https://github.com/apache/netbeans/pull/2783
If that PR got accepted, then (I believe) the new "summary"
class/method
would be available in the API for you to compile against. That's the
pro. On the cons side, the change proposed in #2783 would very likely
mean NetBeans Java support would require `nbjavac` on any JDK<15. I am
not sure our project is ready to make such switch.
Best regards.
-jt
Dne pondělí 8. března 2021 10:44:49 CET, Jakub Herkel napsal(a):
I would like to clarify one thing for me. If I understand correctly
with this new nb-javac we will have only one parser for java sources.
That is superb news (I have had/have lot of problems with parsing,
exceptions,...)
but I still see another problem here (but maybe I missed something) :
When I tried to fix some issues I had to write some ugly code
(NETBEANS-1309): switch(tag.getKind().name()) {
case "SUMMARY" :
try {
Method getSummaryMethod =
tag.getClass().getDeclaredMethod("getSummary");
List<? extends DocTree> summaryList =
(List<? extends DocTree>)getSummaryMethod.invoke(tag);
sb.append(inlineTags(summaryList,
docPath, doc, trees, null));
} catch(NoSuchMethodException |
SecurityException | IllegalAccessException | IllegalArgumentException
| InvocationTargetException ex) {
|
// IGNORE
}
break;
Problem here is that code in the netbeans depends on
com.sun.source.doctree.* classes. But because we need to compile also
with JDK8 we don't have access to new features (for this fix a new
@Summary tag). Could this new nb-javac also help us
with type of "hack"?
jakub
On Sun, Mar 7, 2021 at 7:39 PM Jaroslav Tulach
<jaroslav.tul...@gmail.com> wrote:
Hi.
After enumerating the `nb-javac` deficiencies (below) and writing a
plan
to
address them at our wiki
https://cwiki.apache.org/confluence/display/NETBEANS/
Overview%3A+nb-javac I am here with implementation of the automatic
conversion of JDK16(!, yes we are half a year ahead the plan!)
`javac`.
Please join me in reviewing and discussing the consequences for
NetBeans
here or in the PR#12:
https://github.com/oracle/nb-javac/pull/12
Manually written nb-javac is dead. Long live the new nb-javac!
-jt
On Dec 18, 2020 [I wrote](https://lists.apache.org/thread.html/
r5f210c99b0926aeaac2d0c3c419ff4b79e01f15b67c5ddcf32a51bbe%40%3Cdev.netbeans.apache.org%3E):
Hi.
First and foremost. I admire the work Arvind & his team are doing
while
maintaining [nb-javac](http://github.com/oracle/nb-javac). I am
sure
they
don't hate it. Neither do I, but let's talk about the rest of us
who
have
some concerns...
Our love and hate relationship to nb-javac needs to be
resolved. We
suggest people to go without it, then we suggest people to try
that.
Also with the current release we see an increased amount of
NPE-s and
parsing errors.
Two directions of thinking:
2. we need to get rid of nb-javac.
#2 is a long term (~ a year) thing. I've been discussing
possible ways
to implement #2 and I think it can be done,
if JDK's javac is improved with currently missing IDE-friently
capabilities.
More on that in a separate email later.
OK, this is the email. Let's enumerate the "haters":
- Apache doesn't like `nb-javac` as it is GPLv2+CPEx component
and those
are hard to distribute
- it would be way easier to use plain `javac` from a JDK
- distribution is problematic - needs internet connection and
nb-javac
isn't yet on Maven central
- testers hate `nb-javac` as it multiplies the matrix of things
to test
- each JDK needs to be tested twice - with `nb-javac` and
without
`nb-javac`
- with every bug/problem one needs to know whether `nb-javac`
was or
wasn't in use
- recent version `nb-javac-15` isn't really stable, see
complains on
the
mailing list
- maintainers of JDK's `javac` hate `nb-javac` because it is a
fork of
their own work
- nobody likes forks
- ironically Arvind's team is part of JDK organization - e.g.
it
maintains own fork of JDK's `javac`
Clearly there are numerous drawbacks and we need a way out. Let's
get
rid
of `nb-javac` as we know it. Let's replace it with JDK's own
`javac`!
Great, right? But there are problems...
- `javac` in JDK15 isn't good enough
- compile on save doesn't work
- re-compilation of a single method doesn't work
- runs out of memory more often than `nb-javac`.
Before we can get rid of `nb-javac`, we need to be sure `javac`
in JDK
is
good enough. I let Jan Lahoda (a JDK engineer working on `javac`)
comment
and solve(!) this somehow. Let's now assume JDK17 offers good
enough
`javac`, now we:
- suggest people to use JDK17 when using Apache NetBeans IDE
- not a big problem, JDK17 is LTS, but then?
- if people wanted to use language features of JDK19, they'd
have to
run
on 19!
- that's not what competition does - they support latest
language
features running on JDK11 LTS or even JDK8 LTS
The story may end here and it can be a good enough story for
Apache
NetBeans IDE. However, I don't like it. It is not good enough
story yet.
I
& OracleLabs want to run on LTS and support the latest Java
features. As
such I am ready to make sure JDK17's `javac` runs on JDK8. Can
anything
stop me?
- latest `javac` is written in the language syntax of modern Java
- such syntax cannot be compiled to JDK8 bytecode with `javac`
- latest `javac` is using APIs not available on JDK8
- one needs to rewrite these calls to some older APIs
- the behavior needs to be tested to remain the same
The great revelation is that both these problems can be solved
with
[Jackpot](https://netbeans.apache.org/jackpot/index.html)! Rather
than
maintaining manual patches like `nb-javac` does, let's write
Jackpot
rules
and apply them automatically. For example `Optional.isEmpty()`
method
has
been added in JDK11. Let's add following rule:
```jackpot
$1.isEmpty() :: $1 instanceof java.util.Optional
=>
!$1.isPresent()
;;
```
That automatically rewrites all occurences of
`optional.isEmpty()` to
`!optional.isPresent()` and that is going to compile on JDK8. Few
more
(~30) rules like this and the `javac` is almost ready to run on
JDK8!
Then
we need to run some tests to verify the behavior is same as of
JDK's
`javac` and then we'll be where I want us to be:
People can use Apache NetBeans with `javac` from the latest JDK
or they
can
use the automatic port of the same code running on JDK8. Ideally
the
behavior shall be identical. No more questions: Are you using
nb-javac
or
not? No more duplicated testing matrix.
Moreover vendors of applications built on top of NetBeans can
decide
whether they include `nb-javac` port or not. OracleLabs will
include it
as
we really want our tools to run on GraalVM based on JDK8 and
still
support
the latest Java features.
Let's develop the new `nb-javac` and let's learn to love it!
-jt
-------------------------------------------------------------------
--
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
