Add gtest support on jdk15+ #4134

zzambers · 2025-02-17T18:06:49Z

Adds gtest support for testimage on jdk15+. (in-tree gtest was removed in jdk15) This is needed for some hotspot tests.

Testing:
Tested locally on rhel-8 using command:
./makejdk-any-platform.sh -J /usr/lib/jvm/java-17-openjdk --use-adoptium-devkit gcc-11.3.0-Centos7.9.2009-b03 --build-variant temurin jdk17u
( fixed the issue, build passed, gtest files appeared in test-image in hotspot/gtest )

sbin/build.sh

sbin/prepareWorkspace.sh

judovana · 2025-02-18T09:04:12Z

I worte it quite clumsy. To keep the build offline, but still built gtests by default, I would like to see something like

if  [ -e gtests ] ; then
   addConfigureArg "--with-gtest=...."
else
  if getstAllowed ; then
     downloadGtests
     addConfigureArg "--with-gtest=...."
  fi
fi

where getstAllowed shoudl be true by default, and only if user of build.sh passes something like --no-gtests, or if test image creation is disabled by other logic, it should be false.... wdyt?

zzambers · 2025-02-18T12:05:05Z

I worte it quite clumsy. To keep the build offline, but still built gtests by default, I would like to see something like
if  [ -e gtests ] ; then
   addConfigureArg "--with-gtest=...."
else
  if getstAllowed ; then
     downloadGtests
     addConfigureArg "--with-gtest=...."
  fi
fi
where getstAllowed shoudl be true by default, and only if user of build.sh passes something like --no-gtests, or if test image creation is disabled by other logic, it should be false.... wdyt?

I think download should be kept in prepareWorkspace.sh, but gtest support can be made conditional..

zzambers · 2025-02-18T13:51:07Z

Thanks for feedback, I have made gtest optional. Tested (same way as originally + with --skip-gtest), behaves as expected.

judovana · 2025-02-18T15:27:00Z

Thanx!! Looks nice to me :)

judovana · 2025-02-18T16:10:17Z

Just side note, you tried that image in jtregs then, right?

judovana · 2025-02-18T17:15:01Z

@zzambers Why the checks had not run the build of openjdk? Maybe you need to refresh yours actions setup?

zzambers · 2025-02-19T17:20:10Z

Just side note, you tried that image in jtregs then, right?

I have not tried to run jtregs with generated image, just examined that libraries for gtest are there.

zzambers · 2025-02-19T17:46:52Z

Results in GHA appeared, there i build failure on windows jdk17u (other ones pass). I looked into it a bit:

Error:

d:\a\temurin-build\temurin-build\workspace\build\src\test\hotspot\gtest\metaprogramming\test_enableIf.cpp(73): error C2244: 'TestEnableIfNested<T>::sub1': unable to match function definition to an existing declaration
d:\a\temurin-build\temurin-build\workspace\build\src\test\hotspot\gtest\metaprogramming\test_enableIf.cpp(73): note: see declaration of 'TestEnableIfNested<T>::sub1'
d:\a\temurin-build\temurin-build\workspace\build\src\test\hotspot\gtest\metaprogramming\test_enableIf.cpp(73): note: definition
d:\a\temurin-build\temurin-build\workspace\build\src\test\hotspot\gtest\metaprogramming\test_enableIf.cpp(73): note: 'U TestEnableIfNested<T>::sub1(U)'
d:\a\temurin-build\temurin-build\workspace\build\src\test\hotspot\gtest\metaprogramming\test_enableIf.cpp(73): note: existing declarations
d:\a\temurin-build\temurin-build\workspace\build\src\test\hotspot\gtest\metaprogramming\test_enableIf.cpp(68): note: 'U TestEnableIfNested<T>::sub1(U)'
make[3]: *** [lib/CompileGtest.gmk:88: /cygdrive/d/a/temurin-build/temurin-build/workspace/build/src/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/gtest/objs/test_enableIf.obj] Error 1

Details:
Problem is reproducible (even with older gtest). It fails to compile code introduced in JDK-8258853. Change was not backported to jdk11u, that's why windows build passes there. Build also passes on jdk (newest). I don't see any changes to relevant code in jdk, so I think it is because Visual Studio 2022 is used for jdk, while jdk17u uses Visual Studio 2019.

(Could be bug in older VS (2019), if other systems and also newer VS are not affected. Not yet sure, what to do about it.)

zzambers · 2025-02-24T18:26:00Z

Correction:
All windows builds use VS 2022. Even though GHA workflow installs VS 2019 on jdk11u and jdk17u, configure output shows, that VS 2022 is actually used everywhere:

* Toolchain:      microsoft (Microsoft Visual Studio 2022)
* C Compiler:     Version 19.42.34436 (at /cygdrive/c/progra~1/micros~2/2022/enterp~1/vc/tools/msvc/1442~1.344/bin/hostx86/x64/cl.exe)
* C++ Compiler:   Version 19.42.34436 (at /cygdrive/c/progra~1/micros~2/2022/enterp~1/vc/tools/msvc/1442~1.344/bin/hostx86/x64/cl.exe)

zzambers · 2025-02-24T18:55:19Z

I have done quite a lot of testing locally with VS 2022 today and found, that jdk17 build actually passes with older version of VS 2022:

configure: Using microsoft C compiler version 19.37.32825 [Microsoft (R) C/C++ Optimizing Compiler Version 19.37.32825 for x64]
...
configure: Using microsoft C++ compiler version 19.37.32825 [Microsoft (R) C/C++ Optimizing Compiler Version 19.37.32825 for x64]
...
* Toolchain:      microsoft (Microsoft Visual Studio 2022)
* C Compiler:     Version 19.37.32825 (at /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1437~1.328/bin/hostx86/x64/cl.exe)
* C++ Compiler:   Version 19.37.32825 (at /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1437~1.328/bin/hostx86/x64/cl.exe)

However, after I updated VS 2022, build failed. Versions after update:

configure: Using microsoft C compiler version 19.43.34808 [Microsoft (R) C/C++ Optimizing Compiler Version 19.43.34808 for x64]
...
configure: Using microsoft C++ compiler version 19.43.34808 [Microsoft (R) C/C++ Optimizing Compiler Version 19.43.34808 for x64]
...
* Toolchain:      microsoft (Microsoft Visual Studio 2022)
* C Compiler:     Version 19.43.34808 (at /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1443~1.348/bin/hostx86/x64/cl.exe)
* C++ Compiler:   Version 19.43.34808 (at /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1443~1.348/bin/hostx86/x64/cl.e

Btw jdk21u is also affected (but latest jdk is not).

I have tried to manually apply some changes to relevant files done in newer jdks (to see if I can work around this somehow). There are only small changes (things like sorting includes...) Did not help (maybe changes in another included files?).

There was one change JDK-8347909, which does something about precompiled headers. This gave me an idea to try to run build with --disable-precompiled-headers, but build still failed.. :(

Summary:

seems like bug in recent updates of VS 2022
I still don't know why (latest) jdk is not affected, while jdk17u and jdk21u are affected (could be some special set of conditions, which triggers bug in VS 2022)

zzambers · 2025-02-26T15:49:46Z

I am now in process of bisecting jdk commit, which fixes this issue on newer jdks. (hopefully it will put more light on the problem)

zzambers · 2025-02-26T23:00:52Z

And the winner is JDK-8317132 :)

I don't see any change to relevant code, so it seems like adding -permissive- argument to compiler avoids the issue in newer jdks. This disables permissive mode and sets compiler to strict/standard-conforming behavior according to doc. (notice - in the end)

That is interesting, I would expect permissive mode to be more forgiving and not to fail, where strict/standard-conforming mode passes. I think, it is probably not supposed to be like that and that it is likely bug in VS compiler. I'll probably fill issue to Visual Studio later.

zzambers · 2025-02-27T17:05:31Z

I have filled issue for Visual Studio: https://developercommunity.visualstudio.com/t/OpenJDK-jdk17u-build-failure-with-VS20/10860335

FrankXie05 · 2025-03-03T10:07:02Z

@zzambers Thanks for you posting feedback.

Sorry for leaving a comment here. I saw your feedback and I think it might be more convenient to communicate here.

I think:
The inconsistent declarations of functions ENABLE_IF and ENABLE_IF_SDEFN may cause MSVC parsing failure.

https://github.com/openjdk/jdk17u/blob/ae0177b6abc1c4b3755ec446f2f35ad2616107a9/test/hotspot/gtest/metaprogramming/test_enableIf.cpp#L55

https://github.com/openjdk/jdk17u/blob/ae0177b6abc1c4b3755ec446f2f35ad2616107a9/test/hotspot/gtest/metaprogramming/test_enableIf.cpp#L58

And the stricter SFINAE parsing of MSVC in /permissive- mode may also cause ENABLE_IF parsing failure, especially sub2.

Could you please provide a simple example of this problem? It can be a .cpp or .i file (the file can be replied to Feedbcak).
This way we can locate the problem of a VS version more quickly, and we will solve it quickly. :)

Thanks,
Frank

zzambers · 2025-03-03T15:37:12Z

@FrankXie05 Thank you for the swift reply.
I was able to come with reproducer. I attached it to VS issue.

FrankXie05 · 2025-03-04T02:16:41Z

@zzambers Thank you for the example, this is the result of my local test:
My compiler versions (VS 2022): 19.43.34808.96. And I also tested it with the latest compiler and it didn't work either. 😢

G:\Fe\repro>"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars64.bat"
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.12.5
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

G:\Fe\repro>type test.cpp
#include <type_traits>

#define ENABLE_IF(...) \
  std::enable_if_t<bool(__VA_ARGS__), int> = 0

#define ENABLE_IF_SDEFN(...) \
  std::enable_if_t<bool(__VA_ARGS__), int>

template<typename T, ENABLE_IF(std::is_integral<T>::value)>
static T sub1(T x) { return x - 1; }

template<typename T, ENABLE_IF(std::is_integral<T>::value)>
static T sub2(T x);

template<typename T, ENABLE_IF_SDEFN(std::is_integral<T>::value)>
T sub2(T x) { return x - 2; }

template<typename T>
struct TestEnableIfNested {
  template<typename U, ENABLE_IF(std::is_integral<U>::value)>
  static U sub1(U x);
};

template<typename T>
template<typename U, ENABLE_IF_SDEFN(std::is_integral<U>::value)>
U TestEnableIfNested<T>::sub1(U x) { return x - 1; }

G:\Fe\repro>cl.exe -permissive- -c test.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.43.34808.96 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

test.cpp

G:\Fe\repro>

zzambers · 2025-03-04T11:34:44Z

@zzambers Thank you for the example, this is the result of my local test: My compiler versions (VS 2022): 19.43.34808.96. And I also tested it with the latest compiler and it didn't work either. 😢

@FrankXie05 Didn't work means compiler (i.e. you reproduced this issue) or that reproducer did not work for you?

It is compilation without -permissive- flag, which fails for me:
cl -c reproducer.cpp

Compilation with -permissive- flag is known to pass (counter-intuitively; latest jdk uses this flag and that's why it's not affected).

karianna · 2025-09-10T21:21:04Z

Windows 2022 failure is for downloading gtest: Copilot has this to say:

This isn’t the file or GitHub—it’s your Cygwin wget (linked with GnuTLS) tripping over TLS. Browsers on Windows use a different TLS stack (SChannel), so they keep working while Cygwin’s GnuTLS chokes.

Here’s the fastest way to get unblocked + the durable fix:

Quick workarounds (pick one)

•	Try forcing TLS 1.2 (avoids some GnuTLS/TLS1.3 quirks):

wget --secure-protocol=TLSv1_2 -O googletest-1.16.0.tar.gz
https://github.com/google/googletest/releases/download/v1.16.0/googletest-1.16.0.tar.gz

(This exact switch has helped others seeing “GnuTLS: The request is invalid.”)

•	Use curl (often built against OpenSSL on Cygwin/MSYS) for the download step:

curl -L --proto =https --tlsv1.2 -o googletest-1.16.0.tar.gz
https://github.com/google/googletest/releases/download/v1.16.0/googletest-1.16.0.tar.gz

Proper fix (recommended)

1.	Update Cygwin packages: run setup-x86_64.exe and update at least:
•	wget
•	gnutls / libgnutls30
•	ca-certificates

Recent GnuTLS releases include important TLS fixes; stale versions often manifest exactly as “The request is invalid.” during handshake.

2.	Refresh CA bundle (if you haven’t recently):

/usr/bin/mk-ca-trust
update-ca-trust # if available on your Cygwin

(Out-of-date/incorrect CA bundles typically produce a different error, but it’s quick to rule out.)

Extra diagnostics (if it still fails)
• Check handshake details:

wget -d --secure-protocol=TLSv1_2 https://github.com/...

•	See what ciphers/versions are negotiated:

gnutls-cli -p 443 github.com

•	Rule out middleboxes: ensure https_proxy/HTTP_PROXY aren’t set, and try from a network segment that isn’t doing TLS inspection (browsers often succeed because they trust enterprise roots that CLI tools don’t).

Why this happens

•	TLS version/cipher mismatch or GnuTLS bug → GitHub enforces modern TLS; older GnuTLS builds can mis-negotiate and bail with GNUTLS_E_INVALID_REQUEST (“The request is invalid.”). Forcing TLS 1.2 or upgrading GnuTLS resolves it.

If you share the output of wget -d (with any tokens redacted), I can pinpoint exactly where the handshake goes sideways and tailor the fix to your host.

zzambers · 2025-09-11T14:15:54Z

I think download of googletest is probably just random infra issue.

The other runs show build problem on jdk+win:

d:\a\temurin-build\temurin-build\workspace\build\src\src\java.base\share\classes\java\lang\invoke\MethodHandleNatives.java:558: error: cannot find symbol
                    VarHandleGuards.class, getVarHandleGuardMethodName(guardType),
                    ^
  symbol:   class VarHandleGuards
  location: class MethodHandleNatives
  ...

not yet sure, what is problem there.

zzambers · 2025-09-15T13:50:21Z

I have done some experiments and it seems that build is broken for given commit of adoptium jdk repo:
8f0d036506571ea37d145ba988fa62a6201119ab

Problem has only shwn up for windows/jdk as testing on linux used different ref/commit.
Output shows following (second run in GHA):

windows/jdk:

...
 From https://github.com/adoptium/jdk
 * [new branch]              dev        -> origin/dev
HEAD is now at 8f0d0365065 Merging origin/master HEAD into dev
Checked out origin/dev
INFO: Extracting latest tag for the scmref using git describe since no tag is set in the build config...
fatal: No tags can describe '8f0d036506571ea37d145ba988fa62a6201119ab'.
Try --always, or create some tags.
WARNING: git describe FAILED. There is likely additional error output above (exit code was 128). Trying again using git describe --tags to match a lightweight (non-annotated) tag
fatal: No tags can describe '8f0d036506571ea37d145ba988fa62a6201119ab'.
Try --always, or create some tags.
FINAL WARNING: git describe --tags FAILED. There is likely additional error output above (exit code was 128). Exporting the abbreviated commit hash using git describe --always as a failsafe to /cygdrive/d/a/temurin-build/temurin-build/workspace/target//metadata/scmref.txt
8f0d0365065
checkoutRequiredCodeToBuild succeeded
...

linux/jdk:

...
From https://github.com/adoptium/jdk
 * [new branch]              dev        -> origin/dev
HEAD is now at 050e4d3bff1 Merging origin/master HEAD into dev
Checked out origin/dev
INFO: Extracting latest tag for the scmref using git describe since no tag is set in the build config...
jdk-26+14_adopt-12677-g050e4d3bff1
SUCCESS: TAG FOUND! Exporting to /home/jenkins/workspace/target//metadata/scmref.txt...
checkoutRequiredCodeToBuild succeeded
...

Building using temurin-build passed for me locally (windows; same arguments) as it ended up using different commit. However I was able to reproduce build error, if I tried to build jdk manually from the commit as in windows GHA build.

github-actions bot added the testing Issues that enhance or fix our test suites label Feb 17, 2025

judovana reviewed Feb 18, 2025

View reviewed changes

sbin/build.sh Show resolved Hide resolved

judovana reviewed Feb 18, 2025

View reviewed changes

sbin/prepareWorkspace.sh Show resolved Hide resolved

github-actions bot added the documentation Issues that request updates to our documentation label Feb 18, 2025

zzambers added 2 commits September 8, 2025 18:56

Add gtest support on jdk15+

1a1c35c

Make gtest support optional

1b90531

zzambers force-pushed the gtest-support branch from d914097 to 1b90531 Compare September 8, 2025 16:56

karianna approved these changes Sep 10, 2025

View reviewed changes

Uh oh!

Add gtest support on jdk15+ #4134

Are you sure you want to change the base?

Add gtest support on jdk15+ #4134

Uh oh!

Conversation

zzambers commented Feb 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

judovana commented Feb 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zzambers commented Feb 18, 2025

Uh oh!

zzambers commented Feb 18, 2025

Uh oh!

judovana commented Feb 18, 2025

Uh oh!

judovana commented Feb 18, 2025

Uh oh!

judovana commented Feb 18, 2025

Uh oh!

zzambers commented Feb 19, 2025

Uh oh!

zzambers commented Feb 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zzambers commented Feb 24, 2025

Uh oh!

zzambers commented Feb 24, 2025

Uh oh!

zzambers commented Feb 26, 2025

Uh oh!

zzambers commented Feb 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zzambers commented Feb 27, 2025

Uh oh!

FrankXie05 commented Mar 3, 2025

Uh oh!

zzambers commented Mar 3, 2025

Uh oh!

FrankXie05 commented Mar 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zzambers commented Mar 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

karianna commented Sep 10, 2025

Uh oh!

zzambers commented Sep 11, 2025

Uh oh!

zzambers commented Sep 15, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

zzambers commented Feb 17, 2025 •

edited

Loading

judovana commented Feb 18, 2025 •

edited

Loading

zzambers commented Feb 19, 2025 •

edited

Loading

zzambers commented Feb 26, 2025 •

edited

Loading

FrankXie05 commented Mar 4, 2025 •

edited

Loading

zzambers commented Mar 4, 2025 •

edited

Loading