-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run selected tests with Java 19 #15709
Conversation
I expected this to fail at this point, in |
@@ -576,6 +577,8 @@ jobs: | |||
github.event.client_payload.pull_request.head.sha == github.event.client_payload.slash_command.args.named.sha && | |||
format('refs/pull/{0}/head', github.event.client_payload.pull_request.number) || '' }} | |||
- uses: ./.github/actions/setup | |||
with: | |||
java-version: ${{ matrix.jdk != '' && matrix.jdk || '17' }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Expectedly, https://github.com/trinodb/trino/actions/runs/3911618479/jobs/6686349744
|
CI #13633 |
What about compilation of plugins too? Maven-checks would be nice to have with 19 too. |
How does it affect CI run time? |
Adds 23 mins. |
It would come at an even higher the cost. We're not ready to stop testing with 17. Think of this PR just as a foot in a door for Java 19 compat, we're not going thru the door yet.
That would be mostly testing the maven plugins themselves, not our code. |
I updated some tests
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ExecutorService
change LGTM
Thanks @losipiuk for reviewing it. I added reference to google/guava#6296 in the code comment. |
.isEqualTo("[3.14,1.0E-323,1.0E308,\"NaN\",\"Infinity\",\"-Infinity\",null]"); | ||
.isEqualTo(Runtime.version().feature() >= 19 | ||
? "[3.14,9.9E-324,1.0E308,\"NaN\",\"Infinity\",\"-Infinity\",null]" | ||
: "[3.14,1.0E-323,1.0E308,\"NaN\",\"Infinity\",\"-Infinity\",null]"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
double a = 1.0E-323;
double b = 9.9E-324;
System.out.println(a == b); // true
in both Java 17 and 19. I.e. same value, different representation.
In order to future-proof us for Java update, run selected tests (`trino-main`) with JDK 19 too.
@@ -267,7 +267,9 @@ public void testDoubleToShortDecimalCasts() | |||
assertDecimalFunction("CAST(DOUBLE '-1234567890.0' AS DECIMAL(20,10))", decimal("-1234567890.0000000000", createDecimalType(20, 10))); | |||
assertDecimalFunction("CAST(DOUBLE '1234567890.0' AS DECIMAL(30,20))", decimal("1234567890.00000000000000000000", createDecimalType(30, 20))); | |||
assertDecimalFunction("CAST(DOUBLE '-1234567890.0' AS DECIMAL(30,20))", decimal("-1234567890.00000000000000000000", createDecimalType(30, 20))); | |||
assertDecimalFunction("CAST(DOUBLE '123456789123456784' AS DECIMAL(18,0))", decimal("123456789123456784", createDecimalType(18))); | |||
assertDecimalFunction("CAST(DOUBLE '123456789123456784' AS DECIMAL(18,0))", Runtime.version().feature() >= 19 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a bug somewhere since the resulting numbers are different. If the problem is that the input value doesn't have a precise representation, then we should change the test to have one that does. Ideally, we shouldn't be gating all tests based on the version of the runtime. It makes it harder to reason about correctness.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In any case, it's a behavior change. For same input, same expression Trino on Java 19 produces different results. I am grateful to the test author for writing this test, otherwise I wouldn't know the behavior changed.
Ideally, we shouldn't be gating all tests based on the version of the runtime.
If the results depend on runtime version, then it's a necessity.
The alternative of changing/reducing test coverage isn't exactly as exciting to me.
It makes it harder to reason about correctness.
Agreed!
Fortunately it's easy to compare 17's and 19's expected values, but yet it's a human's job to do that.
OTOH it's temporary. Once we move to 19+ as required runtime, we will remove the conditionality here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a bug somewhere since the resulting numbers are different
If we call it a bug, it would be a correctness bug, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW here are some details
double input = 123456789123456784d;
// 17: "17"
// 18: "18"
// 19: "19"
System.out.println(Runtime.version().feature());
// This is equivalent to part of io.trino.spi.type.DecimalConversions#internalDoubleToLongDecimal
// 17: "123456789123456784000000000000000000"
// 18: "123456789123456784000000000000000000"
// 19: "123456789123456780000000000000000000"
System.out.println(BigDecimal.valueOf(input).setScale(18, HALF_UP).unscaledValue());
// Some more details on the above expression:
// 17: "123456789123456784"
// 18: "123456789123456784"
// 19: "1.2345678912345678E+17"
System.out.println(BigDecimal.valueOf(input));
// java.math.BigDecimal.valueOf(double) uses Double.toString (in Java 17, 18 and 19)
// 17: "1.23456789123456784E17"
// 18: "1.23456789123456784E17"
// 19: "1.2345678912345678E17"
System.out.println(Double.toString(input));
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this https://bugs.openjdk.org/browse/JDK-4511638 ? This is considered a bug in JDK, fixed in 19
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this is expected for Double/Float.toString to have a different ("more" correct) representation in the 19
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @wendigo for the pointer!
I am going to merge this as-is. It's a almost purely test-only change, and there were no concerns about non-test part of that. The problems uncovered are not something I believe is a bug, but in any case they can be fixed as a followup. Alternative would be
|
In order to future-proof us for Java update, run selected tests (
trino-main
) with JDK 19 too.This updates some tests due to Double.toString() and Float.toString() changes in JDK 19.