I love it when it works and hate it when it doesn't. Maybe worth checking how others handle it. This seems to be particular for NetBeans and too many core dependencies/features on it.
On Sat, Dec 19, 2020, 9:53 AM Laszlo Kishalmi <laszlo.kisha...@gmail.com> wrote: > Well, > > Personally I do not hate nb-javac. I do not like the relationship we are > having with it. And the way we are communicating it with the users. Like > we have a new JDK which nb-javac is does not support, we tell the users > go for the JDK. When some exception happens in we say try with nb-javac, > and again if there is something strange with nb-javac we tell the users > do not use nb-javac. Besides of that we are heavily promoting nb-javac, > so most users ending up installing it anyway without really knowing what > is going on. > > In my opinion we should do: > > - Create a separate distribution channel for nb-javac. (AFAIK, Matthias > is working on that), so we can roll out patches independent from > NetBeans and JDK release schedule > - We can add it's update center to our distribution, probably disabled > by default. > - We can have a dialog/notification on Startup promoting it as a > feature, displaying pro-s and cons. > > > On 12/18/20 12:35 PM, Jaroslav Tulach wrote: > > 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 > > > >
