HIVE-28643: Fix "Error getting slot value" for Java 12 and above

[vrozov]

What changes were proposed in this pull request?

Use getDeclaredFields0 to try getting slot Field if getDeclaredField fails. Fallback to the old non deterministic behavior if slot field is not accessible.

Why are the changes needed?

Java 12 and above filters out private fields of the Field class causing "Error getting slot value".

Does this PR introduce any user-facing change?

No

How was this patch tested?

Verified manually that the error is gone on Java 17. Using existing test for the rest.

[kokila-19]

@vrozov
Slot value was used as non-deterministic result would result in flaky test. Falling back to it won't be a good idea.

There is an alternative provided for this so I have already fixed it which is present JDK 17 PR , currently in WIP which will be rebased to the main PR soon.
94c3bb6

Using the MethodHandles privateLookupIn , slot can be accessed.

[vrozov]

@kokila-19

Slot value was used as non-deterministic result would result in flaky test. Falling back to it won't be a good idea.

1. Most of the time there will be no fallback. Field.class.getDeclaredField(name) will work in Java 8 and getDeclaredFields0.invoke will work in Java 12 and above.
2. The fallback is provided as the last resort option to the old not deterministic behavior.

Using the MethodHandles privateLookupIn , slot can be accessed.

It requires JDK 9 and above. Do you suggest that support for JDK 8 is completely dropped in 4.1?

[sonarqubecloud]

Quality Gate passed

Issues
13 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[kokila-19]

Yes. We can't support JDK8 and JDK17 together.
one example is "--add-opens" which won't be recognized by JDK8 because it does not know such an option.
Also, most of the dependencies that are upgraded use jdk17 specifically.

[vrozov]

Yes. We can't support JDK8 and JDK17 together.

It is possible to compile to Java 8 byte code and test both with Java 8 and any other version of Java including 17. IMO, dropping support for Java 8 should be done as part of major version upgrade.

one example is "--add-opens" which won't be recognized by JDK8 because it does not know such an option.

The option applies only at runtime and may be provided for Java 17 only if necessary

Also, most of the dependencies that are upgraded use jdk17 specifically.

Which dependencies? All current dependencies are Java 8 compatible.

[deniskuzZ]

We are dropping support for jdk8 in Hive-4.1. jdk17 would be required for the compilation.