On Fri, Dec 18, 2020 at 11:59 PM Scott Palmer <[email protected]> wrote:
> > > On Dec 18, 2020, at 3:36 PM, Jaroslav Tulach <[email protected]> > 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... > > ... > > > > - 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 > > If such a JDK is installed, NB should use the tooling in it to support the > latest features. > NB should be able to run on JDK 17 while supporting an editor that is > aware of JDK 19 features and using javac from the target JDK as needed. > I think some more details on how to realistically achieve this are needed. An important thing to note is that most of the features of the NetBeans's Java editor have a fairly strong bound to javac APIs (and, in some cases, not-API, but we can keep that aside for now). Specifically, most features use directly APIs like com.sun.source.** and javax.lang.model.** - i.e. the classes for these APIs need to be loaded by the same VM as is running the feature (which does not necessarily need to be the VM that runs the UI, but see below). > > I think the best way forward is to work with plain javac and solve the > “problems” above. > > > 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. > > But why? Just run JDK 17’s javac on JDK 17. If necessary, NB can create a > separate process to handle this. > I think more details on how exactly to achieve this are needed. Nearly all features in the Java editor depend on the javac APIs. So this means nearly all features related to Java editing would need to be re-written - are there volunteers to do that? There are sketches like: https://github.com/apache/netbeans/pull/558 https://github.com/apache/netbeans/pull/1475 But these were never intended to replace all the features, just select ones. In particular error highlighting in the editor + possibly code completion and navigator, but not various refactorings. > > 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. > > I don’t think Jackpot will work for a method reference like > Optional::isEmpty, will it? > It is true that the absence of a target type is somewhat troublesome in matching "Optional::isEmpty", but I don't think that is an insurmountable problem. Jan Jackpot is a workaround, not a solution. > > > 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. > > Instead let’s forget compiling and running on JDK 8. It’s old. We can’t > stay in the past forever. The time has come to move on. Maybe for JDK > 17? A policy of requiring the latest LTS JDK for the latest NB is > reasonable to me. > > > Let's develop the new `nb-javac` and let's learn to love it! > > Doesn’t it make more sense to work toward making regular javac do what is > needed? > > Regards, > > Scott
