Replacing manually built javac with Maven one

[jtulach]

Now, when NetBeans IDE includes JDK-17+35 javac let's get rid of the old JDK-9 langtools Javac. We should be able to replace the manually built javac from langtools9.zip with the official bits. This change offers two sword edge:

• it allows us to use latest Javac API easily (without reflection)
• it prevents us to run on older JDKs than 17 (expect linkage errors)

I guess that's both OK given the fact we bundle Javac binaries and regular end users doesn't have to think about what JDK/javac to use.

[matthiasblaesing]

Getting rid of the custom build of langtools (if I remember correcty langtools relies on nashorn for the build, so will break on JDK15+) is great. I can't comment on the changes to java.source.base. One question though: Would dropping support for building with JDK 8 and requirering JDK 11 (or 9+) be an alternative to the nb-javac binaries? I think this PR is worth it, even if we just move to the prebuild nb-javac, but getting rid of it completely (at least for building the IDE) would be even better. And for me using JDK 11 and build with release 8 sounds like a valid idea.

[neilcsmith-net]

@matthiasblaesing as I said on earlier PR, IMO discussion and schedule on dropping support for a build platform belongs on dev@ not on a PR. I think there are some arguments for keeping min JDK for build and run the same - we make source releases. Somewhat longer term I agreed with you. Perhaps we can bump both to 11 in a year (maybe assuming we have an LTS next Feb)? For now, this sounds like a good interim improvement to me.

[matthiasblaesing]

@neilcsmith-net I asked a question and Java 11 being LTS a valid one. The whole nbjavac mess exists, because we need a more recent compiler than JDK 8 provides. So reality is, that we are already on a JDK 9+ build.

Apart from that, I know, that NetBeans in the past bumped compiler level without bumping runtime jdk. So it worked in the past and there is no reason to expect it to break now.

I build for JNA for JDK 6, so please stop assuming I want to break NetBeans.

[neilcsmith-net]

@matthiasblaesing the nb-javac mess affects build and runtime. I'm not assuming you want to break NetBeans. I'm saying there may be valid reasons people want the build to still support JDK 8 - we release sources! I don't disagree with your point of view (personally I'm in favour of dropping JDK 8 for build and runtime sometime in the near future), but that discussion belongs on dev@ (at least), not here.

[jtulach]

I've got a warning from Jan Lahoda that by using javac-15 as the base APIs we compile against we may compromise ability of our java.source to run with plain JDK's javac on JDK11, JDK12, JDK13, JDK14. As a result of that we might require installation of nb-javac on anything older than JDK-15. Is that an option? If so, I finish the PR and require installation of nb-javac on anything lower than JDK-15. Otherwise I am not sure how exactly to proceed.

[matthiasblaesing]

It would be good to know the full story. @jlahoda could you please give a summary here? This sounds as if building against nbjavac 15 will make it a hard dependency for Java Editing on prior JDKs. This would cement the dependency on a GPL binary.

My gut feeling: We don't get a hard dependency on nbjavac/jdk15, but because we compile against a more recent API, we might use features, only available on later versions of javac. It might be possible to prevent this by using something like animal sniffer (https://www.mojohaus.org/animal-sniffer/animal-sniffer/index.html) to detect incompatibilities.

[jlahoda]

Running the build against langtools9 was intended to avoid accidental dependencies on a APIs that are not available in the base JDKs on which we run (somehow) without nb-javac. Another reason was to avoid accidental dependencies on nb-javac enhancements. If we start to compile against JDK 15's javac, we will loose both parts of this verification. By itself it does not necessarily mean it will stop to work on e.g. JDK 11, but much less checks will be performed.

Frankly, the more I think about this, the more I wonder if we don't want to simply drop running on JDK 15 (and then eventually 16) without nb-javac. The user experience running on JDK 11 without nb-javac leaves a lot to be desired, it is difficult to test, etc. Maybe just being transparent, and saying that we need a fairly up-to-date javac, either in JDK or using nb-javac would be better. And would help us avoid tons of reflective hacks. Not sure I agree this would cement a dependency on the GPLv2+CPE library (more) - we already depend on it pretty hard. Frankly, as is my long-standing opinion, I think it would be both technically better and better user experience to ship nb-javac (of some form) with NetBeans. Not doing that is responsible for almost all the mess, I think.

[matthiasblaesing]

With Jans argument, at this point in time IMHO it makes no sense to replace the langtools build, because we actually don't need nbjavac, but we need the API of the javac at a given minimum revision, we loose the reasoning of build.

[matthiasblaesing]

@jlahoda do I understand you correctly, that bumping API to 15/16 would mean, that the JDK javac and the corresponding nbjavac would work? The reason for my question is, that it shifts the impact, if we rely on a JDK 15/16 javac, we have two (maybe three) fallback compiler packages:

• javac (needs either recent JDK or a repackaging of the javac)
• nbjavac (to my understanding a modified java with better integration than JDK javac)
• frgaal (not sure about this one though)

Only relying on nbjavac would IMHO be an error, but in general nb-javac is to my understand just sometimes a problem, when people try to update without a stable internet connection (or when maven central comes down).

[JaroslavTulach]

The eliminating javac vs. nb-javac differences proposal suggests to automatically generate nb-javac from JDK sources. Here is my PR that implements such idea oracle/nb-javac#12

[geertjanw]

There are two conflicting files, can that be fixed, plus is this ready for 12.4?

[ebarboni]

can this go for 12.5 or should we postpone ?

[neilcsmith-net]

What's the status of this PR? Push back another milestone? Review in light of points about nb-javac bundling?

[JaroslavTulach]

The overall goal of nbjavac plan is to simplify NetBeans codebase, simplify the matrix of various JDK/javac/NetBeans combinations, simplify testing. As such, the ideal future of this PR is to drop the langtools javac here and replace it with the same (automatically generated nb-)javac as used for runtime. Clearly I am not able to do that for 12.6.

[JaroslavTulach]

Looks like we are green at 5f562b5. I am going to squash and merge the changes. The removal of compilation of ancient Javac9, simplification of the codebase and the ability to target just one version of Javac is worth it.