Hi,
For now the simplest is to disable always is an alternate JVM is used,
just remove the second part of the first IF statement. In Main it is no
longer relevant, as the runtime JDK is always >= 17, so it would always
trigger the first if.
I would not spend too much time, until errorprone gets its issues fixed.
Actually they have some hacks but they only work with toolkits. Looks
like the combination fork=true and not using toolkits breaks their
construction of parameters to pass.
Same for Solr.
Am 14.11.2023 um 19:17 schrieb Uwe Schindler:
Hi Dawid,
The problem does not happen on Java 17, because errorprone is not
enabled when the forked JDK is > Java 15. We did this because earlier
versions worked correctly. But new versions of errorprone always fail
when the JDK is forked while compiling.
if (rootProject.usesAltJvm && rootProject.runtimeJavaVersion >
JavaVersion.VERSION_15) {
skipReason = "won't work with JDK
${rootProject.runtimeJavaVersion} if used as alternative java
toolchain"
}
if (!propertyOrDefault("validation.errorprone",
isCIBuild).asBoolean()) {
skipReason = "skipped on builds not running inside CI
environments, pass -Pvalidation.errorprone=true to enable"
}
So it looks like the errorprone plugin got broken by a recent upgrade.
It now always fails when forked JDK is used. So we shold disable it in
this case. We just did not notice, as previously it was only disabled
when the runtime java version was > 17.
Nowadays we no longer run alternate JVMs with Java 12, 13, 14, 15. We
run with Java 11, 17, 19, 20, 21. So it is always disabled except for
Java 11. With RUNTIME_JAVA_HOME==JAVA_HOME we never fork, but as we
use OpenJ9, we fork an BOOOOOM.
I will post a PR soon.
Uwe
Am 14.11.2023 um 19:06 schrieb Uwe Schindler:
Hi Dawid,
Hah, the issue happens only if you pass CI=true (this is set by CI
systems), so errorprone is enabled. so do "export CI=true" and then
build with that config.
So it looks like a combination of errorprone enabled with Java 11 OpenJ9.
Uwe
Am 13.11.2023 um 09:09 schrieb Dawid Weiss:
Sure, thanks. What's strange is that we don't use add-opens
anywhere, I think (there is a mention of it I left in one of the
comments, but nothing else across the codebase uses this directive).
> Task :lucene:distribution.tests:compileTestJava
warning: [options] --add-opens has no effect at compile time
On Sun, Nov 12, 2023 at 10:56 PM Uwe Schindler <u...@thetaphi.de> wrote:
Will check tomorrow, it's too late now.
On Jenkins there were no windows builds with IBM and Java 11
yet: https://jenkins.thetaphi.de/job/Lucene-9.x-Windows/
Am 12.11.2023 um 22:00 schrieb Dawid Weiss:
Hi Uwe,
Can you reproduce this on Windows with the same JVM versions
though? Seems like I have exactly the same setup and yet this
works for me just fine. Strange.
Dawid
On Sun, Nov 12, 2023 at 9:52 PM Uwe Schindler <u...@thetaphi.de>
wrote:
This one was my first idea, too.
It fails only with IBM Semeru in combination with Gradle
using Temurin.
I will dig tomorrow on Jenkins server and print all debug info.
Uwe
Am 12. November 2023 21:48:54 MEZ schrieb Dawid Weiss
<dawid.we...@gmail.com>:
I can't reproduce this though - used exactly the same
JVMs (on Windows):
> gradlew :lucene:distribution.tests:compileTestJava
--rerun-tasks --console=plain
Generating gradle.properties
...
> Task :altJvmWarning
NOTE: Alternative java toolchain will be used for
compilation and tests:
Project will use 11 (IBM JDK 11.0.20.1+1, home at:
c:\_tmp\jdk-11.0.20.1+1)
Gradle runs with 11 (Eclipse Temurin JDK 11.0.21+9,
home at: C:\_tmp\jdk-11.0.21+9)
...
> Task :lucene:distribution.tests:compileJava NO-SOURCE
> Task :lucene:distribution.tests:classes UP-TO-DATE
> Task :lucene:distribution.tests:compileTestJava
BUILD SUCCESSFUL in 23s
5 actionable tasks: 5 executed
On main branch it works, no idea why:
O thought it's because of this:
https://github.com/apache/lucene/commit/2e12a35c876a
but I don't think so... seems to work for me on Windows
on branch_9x just fine?
D.
--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail:u...@thetaphi.de
--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail:u...@thetaphi.de
--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail:u...@thetaphi.de
--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail:u...@thetaphi.de
