bcgit
Current main fails tests
MacOS Sonoma 14.3, Azul JDK-21.
$ java -version
openjdk version "21.0.2" 2024-01-16 LTS
OpenJDK Runtime Environment Zulu21.32+17-CA (build 21.0.2+13-LTS)
OpenJDK 64-Bit Server VM Zulu21.32+17-CA (build 21.0.2+13-LTS, mixed mode, sharing)
Cannot invoke "String.length()" because "prefix" is null
java.lang.NullPointerException: Cannot invoke "String.length()" because "prefix" is null
at java.base/java.lang.String.startsWith(String.java:2285)
at java.base/java.lang.String.startsWith(String.java:2327)
at org.bouncycastle.crypto.test.JVMAssertionTest.testVersion(JVMAssertionTest.java:13)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
at junit.extensions.TestSetup.run(TestSetup.java:27)
Update
Needless to say that on all of my systems System.getProperty("test.java.version.prefix") returns null. I wonder who added this ~~stupid~~ useless test, and respectfully request removing it.
Right, sorry about that..
We have been upgrading our build and moving to centralising test running via gradle and we needed to test across multiple JVMs and that test was to verify it was running the JVM version we were expecting it to run and should not have made it to the outside world.
We've deleted the errant test from github. We'll need to replace it with something equivalent as it's proved to be very easy to be running a multi-release jar on something other than the JVM you think you're testing, looking for a more general solution.
Just another note, we're going to be dropping ant for the 18on builds - the combination of ant/shell doesn't work for the latest OSGI with multi-versioning so we need to move the 18on builds to Gradle, expect this to happen over the coming month.
Just another note, we're going to be dropping ant for the 18on builds - the combination of ant/shell doesn't work for the latest OSGI with multi-versioning so we need to move the 18on builds to Gradle, expect this to happen over the coming month
How should one do the build then, and what are the requirements besides having Gradle installed? I.e., is this sufficient?
$ gradle --version
------------------------------------------------------------
Gradle 8.5
------------------------------------------------------------
Build time: 2023-11-29 14:08:57 UTC
Revision: 28aca86a7180baa17117e0e5ba01d8ea9feca598
Kotlin: 1.9.20
Groovy: 3.0.17
Ant: Apache Ant(TM) version 1.10.13 compiled on January 4 2023
JVM: 21.0.2 (Azul Systems, Inc. 21.0.2+13-LTS)
OS: Mac OS X 14.3 x86_64
$
So we've gone the gradlew path, but yes gradle 8.5 is about right, you'll need to look in the current README.md for details there's a few environment variables that need to be set.
@dghgit I'm unhappy to report that gradlew build fails miserably:
$ time ./gradlew clean build
Downloading https://services.gradle.org/distributions/gradle-8.5-bin.zip
Exception in thread "main" java.io.IOException: Server returned HTTP response code: 403 for URL: https://objects.githubusercontent.com/github-production-release-asset-2e65be/696192900/dcd9afce-797b-4c7f-9704-6decd18882ea?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAVCODYLSA53PQK4ZA%2F20240205%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240205T155827Z&X-Amz-Expires=300&X-Amz-Signature=0adb19d8f5ba9132127d54d74036b1f3bc3e155b9bd1f509ee715c6924e535df&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=696192900&response-content-disposition=attachment%3B%20filename%3Dgradle-8.5-bin.zip&response-content-type=application%2Foctet-stream
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:2011)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1602)
at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:223)
at org.gradle.wrapper.Download.downloadInternal(Download.java:109)
at org.gradle.wrapper.Download.download(Download.java:89)
at org.gradle.wrapper.Install$1.call(Install.java:83)
at org.gradle.wrapper.Install$1.call(Install.java:63)
at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:69)
at org.gradle.wrapper.Install.createDist(Install.java:63)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:109)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:66)
real 0m2.230s
user 0m1.111s
sys 0m0.168s
Since gradle is installed locally (as you can see form my previous post) - why does your script insist on downloading it again is beyond me.
I must add that I, like robably many other users, don't need multi-version builds. So, it would be nice to preserve and maintain the ant builds for users like myself.
gradlew is actually a gradle provided convenience tool - I'd guess there's either a transient issue or a firewall/proxy-cache issue (403 is Forbidden, a bit odd to get that given you can download it). You can also use gradle-8.5 on the command line instead - gradlew just makes sure you've got the correct version.
You can also use gradle-8.5 on the command line instead - gradlew just makes sure you've got the correct version
OK, thanks. Trying with gradle, it still fails:
$ time gradle clean --stacktrace --info 2>&1 | tee gradle-build.txt
Initialized native services in: /Users/ur20980/.gradle/native
Initialized jansi services in: /Users/ur20980/.gradle/native
Received JVM installation metadata from '/Library/Java/JavaVirtualMachines/zulu-21.jdk/Contents/Home': {JAVA_HOME=/Library/Java/JavaVirtualMachines/zulu-21.jdk/Contents/Home, JAVA_VERSION=21.0.2, JAVA_VENDOR=Azul Systems, Inc., RUNTIME_NAME=OpenJDK Runtime Environment, RUNTIME_VERSION=21.0.2+13-LTS, VM_NAME=OpenJDK 64-Bit Server VM, VM_VERSION=21.0.2+13-LTS, VM_VENDOR=Azul Systems, Inc., OS_ARCH=x86_64}
The client will now receive all logging from the daemon (pid: 35347). The daemon log file: /Users/ur20980/.gradle/daemon/8.5/daemon-35347.out.log
Starting 3rd build in daemon [uptime: 1 mins 52.819 secs, performance: 100%, GC rate: 0.00/s, heap usage: 0% of 2 GiB]
Using 20 worker leases.
Now considering [/Users/ur20980/src/bc-java] as hierarchies to watch
Watching the file system is configured to be enabled if available
File system watching is active
Starting Build
Settings evaluated using settings file '/Users/ur20980/src/bc-java/settings.gradle'.
Projects loaded. Root project using build file '/Users/ur20980/src/bc-java/build.gradle'.
Included projects: [root project 'bc-java', project ':core', project ':jmail', project ':mail', project ':mls', project ':pg', project ':pkix', project ':prov', project ':test', project ':tls', project ':util']
> Configure project :
Evaluating root project 'bc-java' using build file '/Users/ur20980/src/bc-java/build.gradle'.
Environment setup:
Looking for JDK ENV 'BC_JDK8' found null
FAILURE: Build failed with an exception.
* Where:
Build file '/Users/ur20980/src/bc-java/build.gradle' line: 21
* What went wrong:
A problem occurred evaluating root project 'bc-java'.
> Looking for JDK ENV 'BC_JDK8' but found null, see README 'Environmental variables'
. . .
at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:91)
... 164 more
BUILD FAILED in 516ms
Watched directory hierarchies: []
$ env | grep BC_J
BC_JDK21=/Library/Java/JavaVirtualMachines/zulu-21.jdk/Contents/Home
$ env | grep JAVA
JAVA_OPTS=-Dhttp.proxyHost=llproxy.llan.ll.mit.edu -Dhttp.proxyPort=8080
JAVA_HOME=/Library/Java/JavaVirtualMachines/zulu-21.jdk/Contents/Home
$
I don't need to state that JDK-8 has been gone from my systems for ages now. We've just retired JDK-17, and are on JDK-21.
Update
You realize that the behavior of this Groovy code fragment is to check for env var BC_JDK8 and abort if it's not set? And do the same for each of them? So, that if any of the JDK (8, 11, 17, 21) is missing - the build would abort?!
println("Environment setup:")
["BC_JDK8", "BC_JDK11", "BC_JDK17", "BC_JDK21"].each({ it ->
println("Looking for JDK ENV '${it}' found ${System.getenv(it)}");
if (System.getenv(it) == null) {
throw new RuntimeException("Looking for JDK ENV '${it}' but found null, see README 'Environmental variables'");
}
})
Update 2
Gradle builds seem totally broken (everywhere except, probably, your own environment). After I removed that part of the script that insisted on all the four JDKs being available for the build:
> Configure project :
Evaluating root project 'bc-java' using build file '/Users/ur20980/src/bc-java/build.gradle'.
Environment setup:
Looking for JDK ENV 'BC_JDK21' found /Library/Java/JavaVirtualMachines/zulu-21.jdk/Contents/Home
. . .
------------------------------------------------------------------------
Detecting the operating system and CPU architecture
------------------------------------------------------------------------
os.detected.name=osx
os.detected.arch=x86_64
os.detected.bitness=64
os.detected.version=14.3
os.detected.version.major=14
os.detected.version.minor=3
os.detected.classifier=osx-x86_64
> Configure project :pg
Evaluating project ':pg' using build file '/Users/ur20980/src/bc-java/pg/build.gradle'.
> Configure project :pkix
Evaluating project ':pkix' using build file '/Users/ur20980/src/bc-java/pkix/build.gradle'.
> Configure project :prov
Evaluating project ':prov' using build file '/Users/ur20980/src/bc-java/prov/build.gradle'.
file or directory '/Users/ur20980/src/bc-java/prov/src/test11/java', not found
file or directory '/Users/ur20980/src/bc-java/prov/src/test17/java', not found
file or directory '/Users/ur20980/src/bc-java/prov/src/test21/java', not found
> Configure project :test
Evaluating project ':test' using build file '/Users/ur20980/src/bc-java/test/build.gradle'.
> Configure project :tls
Evaluating project ':tls' using build file '/Users/ur20980/src/bc-java/tls/build.gradle'.
> Configure project :util
Evaluating project ':util' using build file '/Users/ur20980/src/bc-java/util/build.gradle'.
All projects evaluated.
Task name matched 'build'
Selected primary task 'build' from project :
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':jmail:compileJava'.
> Failed to query the value of extension 'errorprone' property 'enabled'.
> Failed to calculate the value of task ':jmail:compileJava' property 'javaCompiler'.
> No matching toolchains found for requested specification: {languageVersion=17, vendor=any, implementation=vendor-specific} for MAC_OS on x86_64.
> No locally installed toolchains match and toolchain auto-provisioning is not enabled.
In summary, I urge you to keep supporting ant builds. If gradle builds work for you - great, but it surely won't be in usable shape for folks like myself in a foreseeable future.
We're going to continue supporting ant for the JDK1.5 and earlier, but I'm not sure this is such a good idea for 1.8 and later - the problem with the current ant build1-8+ is it's building for 1.8 and then hoping for the best - from Java 17 and up, this isn't such a good idea as the JVM's have made internal changes which actually expect later classes such as keys implementing XDH or EdDSA to appear. This particularly applies to the JSSE API.
To deal with this properly we'd really need is separate ant script for every JVM. I'm not sure how you're approaching this at the moment, but while it might appear to be working, it might not really be, you just haven't run into any of the problem cases yet.
We're going to continue supporting ant for the JDK1.5 and earlier . . .
No offense meant - but I don't think anybody (maybe a few of your paying customers) is still on JDK-1.5. Besides, what's the point of using updated security-related middleware on an unmaintained abandoned JDK?
As Oracle says:
Public support and security updates for Java 1.5 ended in November 2009. Paid security updates for Oracle customers ended in April 2015.
It's 2024 now, right?
. . . but I'm not sure this is such a good idea for 1.8 and later
It is an excellent idea - because it works, as my own experience confirms. Now with JDK-21.
To deal with this properly we'd really need is separate ant script for every JVM.
Well, there's JDK-8, JDK-11, JDK-17, and JDK-21. In total, four probably rather similar scripts.
I'm not sure how you're approaching this at the moment, but while it might appear to be working, it might not really be, you just haven't run into any of the problem cases yet.
I'd much rather have it "appear to be working" (it passes all your tests, and my tests, so far) than just plainly failing to build at all, as with Gradle. And who knows - perhaps I'll never run into "any of the problem cases".