javac wrapper module should clean its "external" folder.

[mbien]

• caused compiler errors since several javac versions were in cp (if the local copy is old)
• removed javac.source property since the module has no sources anyway

[matthiasblaesing]

Why is this necessary? Different external dependency have differently named jars. The jars are referred to including the version. I don't see option for problems.

There are instances, where we build "external" jars at build time (inject OSGI header), but apart from that external jars should be downloaded asis.

[mbien]

i pulled from master and it didn't compile anymore, cleaning the folder solved the issue, "ant clean" alone did not.

[matthiasblaesing]

This still leaves the question of the why? What was the error, what failed?

[mbien]

i don't have the log anymore. But some modules could not compile since they expect having JDK 17 javac now, methods were not there, some overrides did not override anything -> compiler error.

Since I compiled on JDK 17 and ant clean did not change anything, the only explanation was that some old nb-javac was still used somehow, so i investigated.

[mbien]

one error I remember was that BindingPatternTree.getVariable() could not be found (as used in org.netbeans.modules.java.source.transform.TreeDuplicator), only JDK 17 has the method.

[matthiasblaesing]

My point is, that we have several modules, where external files are downloaded, adding special cases sprinkled through the build system should be based on a error diagnosis, not on "worked for me" basis. If we know what went wrong, we can fix that.

My take on these kinds of flakiness: If a build fails for me for no apparent reason, I run git clean -f -x -d over the checkout and try again.

[jlahoda]

The javacapi jar is a bit non-standard, as it does not follow the normal modular rules at build time. It is prepended on the bootclasspath, to override the versions from rt.jar (on JDK 8). (It might be possible to do some better tricks on JDK 9+, but that probably means either --patch-module or --limit-modules, and was not really tried so far.)

Originally, the correct jar(s) was(/were) hardcoded in projectized.xml:
https://github.com/apache/netbeans/blame/04ed0908b1acb1fee63425f2dd38ad1384a34b84/nbbuild/templates/projectized.xml#L90

This was changed by:
c1d0699

To use any jar from the external folder:

netbeans/nbbuild/templates/projectized.xml

Line 92 in dcc34cd

<fileset dir="${nb_all}/java/libs.javacapi/external/" erroronmissingdir="false">

This makes changing the nb-javac version easier, but is more prone to trouble if there are stray jars in the external. So cleaning them is surely one viable way to improve stability.

[matthiasblaesing]

@jlahoda thank you for the explanation, with that comment the observed behavior makes sense and more importantly the fix from @mbien looks like the sane approach.

[mbien]

perfect. I think this change is simple enough that we don't have to wait for another reviewer -> going to merge it. Thanks for reviewing.