Looking at adoptium/temurin-build#2178, it's a failure to build the JVM, so there is no -version output. I don't see anywhere in the output where the OpenJ9 and OMR SHAs are shown. The get_j9_source.sh script could print them out after doing a clone.

The OpenJ9 builds determine the SHAs ahead of time and specify them to the script, but Adopt and other builds don't do this.

See eclipse-openj9/openj9#7248

 javax/security/auth/login/modules/JaasModularClientTest.java.JaasModularClientTest
 javax/security/auth/login/modules/JaasModularDefaultHandlerTest.java.JaasModularDefaultHandlerTest
 sun/security/mscapi/CastError.java.CastError
 sun/security/mscapi/InteropWithSunRsaSign.java.InteropWithSunRsaSign
 sun/security/mscapi/KeyStoreEmptyCertChain.java.KeyStoreEmptyCertChain
 sun/security/mscapi/PublicKeyInterop.java.PublicKeyInterop
 sun/security/mscapi/RSAEncryptDecrypt.java.RSAEncryptDecrypt
 sun/security/mscapi/ShortRSAKeyWithinTLS.java.ShortRSAKeyWithinTLS
 sun/security/mscapi/SignUsingNONEwithRSA.java.SignUsingNONEwithRSA
 sun/security/mscapi/SignUsingSHA2withRSA.java.SignUsingSHA2withRSA
 sun/security/mscapi/SignatureOffsets.java.SignatureOffsets
 sun/security/mscapi/SignedObjectChain.java.SignedObjectChain
 sun/security/mscapi/SmallPrimeExponentP.java.SmallPrimeExponentP
 sun/security/pkcs12/P12SecretKey.java.P12SecretKey
 sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java.FileInputStreamPoolTest
 com/sun/net/httpserver/SelCacheTest.java.SelCacheTest
com/sun/net/httpserver/Test12.java.Test12
 com/sun/net/httpserver/Test9.java.Test9
 com/sun/net/httpserver/Test9a.java.Test9a
 java/net/URLClassLoader/B7050028.java.B7050028
 java/net/URLConnection/UnknownContentType.java.UnknownContentType
 java/security/KeyPairGenerator/FinalizeHalf.java.FinalizeHalf
 java/security/Provider/SecurityProviderModularTest.java.SecurityProviderModularTest
 java/security/Signature/ResetAfterException.java.ResetAfterException
 java/security/Signature/SignatureLength.java.SignatureLength
 sun/net/www/protocol/file/FileMap.java.FileMap
 sun/net/www/protocol/file/GetLastModified.java.GetLastModified

Details in attached jtr files:
jtr_test_output.tar.gz

#282 should be contributed to OpenJDK.
@andrew-m-leonard

This causes the jobs to consume valuable space on our worker machine.

Recommend adding a try/finally block around the code.

node ('worker') {
    try {
        // Stuff
    } finally {
        cleanWs()
    }
}

Disabled the jobs temporarily
https://ci.eclipse.org/openj9/view/Infrastructure/job/CopyrightCheck-OpenJDK/
https://ci.eclipse.org/openj9/view/Infrastructure/job/CopyrightCheck-OpenJDK12/
https://ci.eclipse.org/openj9/view/Infrastructure/job/CopyrightCheck-OpenJDK11/
https://ci.eclipse.org/openj9/view/Infrastructure/job/CopyrightCheck-OpenJDK8/

The eclipse/openj9-systemtest repository includes Eclipse .project files, enabling users to check out the repository directly into an Eclipse IDE and exploit the IDE features such as dynamic compilation and debugging.

.project files are not currently excluded from the PR copyright checker which, as automatically generated files, they should be.

#260 should be contributed to OpenJDK.
@andrew-m-leonard

Although ibmruntimes/openj9-openjdk-jdk8 and 9 removed them (ibmruntimes/openj9-openjdk-jdk8#18), a subset of the executables unsupported by OpenJ9 are present in jdk (and 10, 11) builds.

jinfo
jps
jmap
jstack
jstat

Also
ibmruntimes/openj9-openjdk-jdk10#47
ibmruntimes/openj9-openjdk-jdk11#1

The CMake code should now be able to handle cross compile builds. This issue is to track any problems / objections anybody has before making cross-compile builds use cmake by default. CMake builds can currently be tested by passing --with-cmake when calling configure. In addition, where CMake is used by default, uma can still be used by passing --without-cmake.

Merge master HEAD into openj9-staging #322 includes 8255557: Decouple GCM from CipherCore 55387a2 which moved GCM within com.sun.crypto.provider.CipherCore via 278b628, and effectively removed OpenJ9 JCL patch for NativeGCM while NativeCBC still stays.

NativeGCM implementation requires revisiting and to be re-enabled.

fyi @ashbm5

If the SunPKCS11 provider is specified on the getInstance call a no such provider exception will be thrown. If no provider is specified on the getInstance call the first provider in the java security provider list will be used, if the customer is relying on the provider order and have placed SunPKCS11 above others with the intent of using that provider, it will not be used, another provider will be used without notifying the customer. Thus if the customer is relying on the use of Crypto cards for auditing or to meet requirements they will have a silent failure in their process. When debugging why the SunPKCS11 provider is not being used, one might specify -Djava.security.debug=sunpkcs11, there will be no output. Thus there is no indication of what the cause of the problem is.

We've just gotten OpenJ9 testing running for jdknext, and enabled openssl support. The following problems are found.

https://ci.eclipse.org/openj9/job/Build_JDKnext_x86-64_mac_Nightly/28/

00:48:11  /Users/jenkins/workspace/Build_JDKnext_x86-64_mac_Nightly/closed/src/java.base/macosx/native/libjncrypto/NativeCrypto_md.c:63:14: error: implicit declaration of function 'dlinfo' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
00:48:11      if (0 != dlinfo(handle, RTLD_DI_ORIGIN, library_path)) {
00:48:11               ^
00:48:11  /Users/jenkins/workspace/Build_JDKnext_x86-64_mac_Nightly/closed/src/java.base/macosx/native/libjncrypto/NativeCrypto_md.c:63:29: error: use of undeclared identifier 'RTLD_DI_ORIGIN'
00:48:11      if (0 != dlinfo(handle, RTLD_DI_ORIGIN, library_path)) {
00:48:11                              ^
00:48:11  2 errors generated.

https://ci.eclipse.org/openj9/job/Build_JDKnext_ppc64_aix_Nightly/28/

01:21:41  "/home/u0020236/workspace/Build_JDKnext_ppc64_aix_Nightly/closed/src/java.base/aix/native/libjncrypto/NativeCrypto_md.c", line 65.29: 1506-045 (S) Undeclared identifier RTLD_DI_ORIGIN.

ibmruntimes/openj9-openjdk-jdk11#670 (comment)

Strange: the test job didn't use this change; instead it used the [current openj9 branch - b33416dc888](https://github.com/ibmruntimes/openj9-openjdk-jdk11/commit/b33416dc888ee757c6761810bf416f37c6b17e8a).

I think this is a known issue as well, the test change is not picked up, it was determined a low priority item.

FYI @AdamBrousseau

See ibmruntimes/openj9-openjdk-jdk17#166 (comment) for an explanation of why the size of padding elements is incorrect in CallGeneratorHelper.

On RHEL 7, the libcrypto library is not loaded. Looking at the library names on the machine, the library used for 1.0.x is not currently supported.

        libcrypto.so.10 (libc6,x86-64) => /lib64/libcrypto.so.10
        libcrypto.so.10 (libc6) => /lib/libcrypto.so.10
        libcrypto.so.6 (libc6,x86-64) => /lib64/libcrypto.so.6

-rwxr-xr-x 1 root root 1440264 Mar  4  2016 libcrypto.so.0.9.8e
-rwxr-xr-x 1 root root 2512264 May 17  2017 libcrypto.so.1.0.2k
lrwxrwxrwx 1 root root      19 Sep  3  2017 libcrypto.so.10 -> libcrypto.so.1.0.2k
lrwxrwxrwx 1 root root      19 Mar 20  2016 libcrypto.so.6 -> libcrypto.so.0.9.8e

    const char *libname = "libcrypto.so.1.1";    // Library name for OpenSSL 1.1.0 and 1.1.1
    const char *oldname = "libcrypto.so.1.0.0";  // Library name for OpenSSL 1.0.2
    const char *symlink = "libcrypto.so";        // Library name for possible symbolic links

Copied from ibmruntimes/openj9-openjdk-jdk8#57

If smt is enabled the correct number of processors is not correct on configure.

There are a number of ways that can be used to determine actual number of processors, I found this works for me on the systems I have access to, smt enabled or not at time of configure

--with-jobs='pmcycles -m | wc -l | awk '{print $1}''

Current openjdk-tag.gmk content:

OPENJDK_TAG := jdk-20+25

jdk-20+26 is already in the repo.

This is a mismatch, openjdk-tag.gmk missed a update.

https://ci.eclipse.org/openj9/job/Build_JDKnext_x86-64_windows_OpenJDK/77

22:57:15  c:/Users/jenkins/workspace/Build_JDKnext_x86-64_windows_OpenJDK/src/jdk.jdwp.agent/windows/native/libjdwp/linker_md.c(113): error C2220: warning treated as error - no 'object' file generated
22:57:15  c:/Users/jenkins/workspace/Build_JDKnext_x86-64_windows_OpenJDK/src/jdk.jdwp.agent/windows/native/libjdwp/linker_md.c(113): warning C4028: formal parameter 2 different from declaration

openj9 branch is
dbgsysBuildLibName(char *holder, size_t holderlen, const char *pname, const char *fname)

while openj9-staging and master branch is
dbgsysBuildLibName(char *holder, int holderlen, const char *pname, const char *fname)

Addressed by ibmruntimes/openj9-openjdk-jdk8#107 for Windows jdk8, but should be fixed for other platforms and other jdk versions.

Adopting RI java.lang.Thread/ThreadGroup can be enabled via --enable-openjdk-thread-support at JavaNext extension repo. This is to support project loom.

This will be ported to other Java levels according to priorities.

The custom-hook.m4 logic to determine the "based -on " queries all jdk matching tags across the whole repo, meaning if more recent levels have been merged into master, then a build of openj9 branch which does not have those reachable will still display them.
Eg.jdk11 openj9 branch is in fact at jdk-11.0.3+2, but as master & openj9-0.14 have jdk-11.0.3+7 it incorrectly chooses that level.

• Webhook
• @genie-openj9 added to collaborators
• Copyright jenkins copyright check
• Sign-off-by jenkins signed off by check
• Line Endings jenkins line endings check

Openj9PropsExt.java need to be updated to support setting Properties required by @requires expressions.

For example Property vm.bits, otherwise tests with @requires property will be skipped.

eclipse-openj9/openj9#11048

Seems OpenJDK added Github actions to their repo recently

https://github.com/ibmruntimes/openj9-openjdk-jdk/commits/openj9/.github/workflows/submit.yml

This will cause these checks to run on our PRs.
Few options to take

1. Disable GitHub actions complete on our repo(s)
2. Remove the file from the OpenJ9 branch. Will likely cause merge conflicts every time they update the file(s)
3. Fix the file so it works for OpenJ9 build/test. This will cause merge conflicts less often than removing the file completely.

ibmruntimes/openj9-openjdk-jdk8#210
https://ci.eclipse.org/openj9/job/PullRequest-CopyrightCheck-OpenJDK8/345/

14:11:32 The following files were modified and have incorrect copyrights
[Pipeline] echo
14:11:32 common/autoconf/generated-configure.sh
14:11:32 	IBM Copyright (basic) is missing from the file
[Pipeline] echo
14:11:32 jdk/make/closed/autoconf/generated-configure.sh
14:11:32 	IBM Copyright (basic) is missing from the file

there are IBM copyrights, but not in the first 100 lines.

This issue relates to eclipse-openj9/openj9#12276 (comment)

For jdk8, serviceability tests are defined in hotspot_serviceability target. When attempting to run this target against openj9, there appears not be a hotspot/test/TEST.groups file where this target is normally defined in a typical jdk8u mirror (see: https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/hotspot/test/TEST.groups#L141-L142).

From https://openj9-jenkins.osuosl.org/view/Test/job/Grinder/80/console:

12:47:58  Error: Group spec does not specify a valid test suite: /home/jenkins/workspace/Grinder/aqa-tests/TKG/../openjdk/openjdk-jdk/hotspot/test:hotspot_serviceability
12:47:58  
12:47:58  hotspot_serviceability_1_FAILED

Builds are missing the java*.properties files that should be present in the image/jdk/lib directory, as well as the options.default file.

Tested with a build from June 27th.

Rename github.com:ibmruntimes/openj9-openjdk-jdk "jdk" & "openj9-jdk" branches to be consistent with jdk 8/9/10/11, where they are called master & openj9

• 1. Initally duplicate the branches ie. jdk->master, openj9-jdk->openj9
• 2. Communicate about using new branches, and update auto-merge to push to new branches, and any build jobs.
• 3. Delete the old branches

There seems to be a perf regression between these two builds

Before:
https://openj9-artifactory.osuosl.org/artifactory/ci-openj9/Build_JDK11_x86-64_linux_criu_P[…]/OpenJ9-JDK11-x86-64_linux_criu-20220322-120105.tar.gz

openjdk version "11.0.15-internal" 2022-04-19
OpenJDK Runtime Environment (build 11.0.15-internal+0-adhoc.jenkins.BuildJDK11x86-64linuxcriuPersonal)
Eclipse OpenJ9 VM (build master-2ea2b1ea4ce, JRE 11 Linux amd64-64-Bit Compressed References 20220322_5 (JIT enabled, AOT enabled)
OpenJ9   - 2ea2b1ea4ce
OMR      - 644b9078b90
JCL      - f8e09fe3452 based on jdk-11.0.15+6)

After:
https://openj9-artifactory.osuosl.org/artifactory/ci-openj9/Build_JDK11_x86-64_linux_criu_P[…]/OpenJ9-JDK11-x86-64_linux_criu-20220323-141300.tar.gz

openjdk version "11.0.15-internal" 2022-04-19
OpenJDK Runtime Environment (build 11.0.15-internal+0-adhoc.jenkins.BuildJDK11x86-64linuxcriuPersonal)
Eclipse OpenJ9 VM (build master-2ea2b1ea4ce, JRE 11 Linux amd64-64-Bit Compressed References 20220323_6 (JIT enabled, AOT enabled)
OpenJ9   - 2ea2b1ea4ce
OMR      - 644b9078b90
JCL      - 2e2a51b2f0d based on jdk-11.0.15+6)

The openj9/omr versions are the same, which makes me think that ibmruntimes/openj9-openjdk-jdk11#486 is the cause.

Just noticed that there are some strange tag number difference among extension repos.

https://github.com/ibmruntimes/openj9-openjdk-jdk8 - 104 tags
https://github.com/ibmruntimes/openj9-openjdk-jdk11 - 642 tags
https://github.com/ibmruntimes/openj9-openjdk-jdk16 - 1361 tags
https://github.com/ibmruntimes/openj9-openjdk-jdk17 - 717 tags
https://github.com/ibmruntimes/openj9-openjdk-jdk - 1385 tags

JDK17 has much less number of tags than JDK head and JDK16 which is strange.
Also noticed that JDK16 & JDK have many hg-jdk-* tags which shouldn't in these repos, these extra tags probably are the reason why JDK16 has more tags than JDK17.

fyi @AdamBrousseau @pshipton @keithc-ca

Any time there is a change to the openj9 branch in an extensions repo, the staging branch is updated as well by the automated merge process, and this causes an unnecessary acceptance build to occur.

See discussions here:
eclipse-openj9/openj9#7827 (comment)
eclipse-openj9/openj9#7827 (comment)

Currently we do not zip the debug symbols into the SDKs built at https://ci.eclipse.org/openj9/, making it hard to see the native stack information from a core file generated from a test failure.

extended.openjdk PR build still shows the errors eclipse-openj9/openj9#16074 due to the test framework taking the default JDK19 extension repo instead of this PR.
Launched an internal grinder w/ this change and the three tests in question are skipped or passed.

Originally posted by @JasonFengJ9 in ibmruntimes/openj9-openjdk-jdk19#34 (comment)

FYI @llxia @AdamBrousseau