Run CI with Java 17 and 21 #5874
Conversation
andreaTP
requested review from
manusa,
oscerd,
rohanKanojia,
shawkins and
sunix
as code owners
andreaTP
force-pushed
the
check-java-17-21
branch
from
820c214 to
51c3fb1
Compare
andreaTP
force-pushed
the
check-java-17-21
branch
from
51c3fb1 to
125e2d8
Compare
|
ready for review 🎉 cc. @manusa |
| @@ -302,6 +302,7 @@ void bigNumbersSupported(@TempDir Path tempDir) throws Exception { | |||
| // When | |||
| final Path toUploadWithModifiedDate = Files.copy(toUpload, tempDir.resolve("upload-sample.txt")); | |||
| assertTrue(toUploadWithModifiedDate.toFile().setLastModified(9999999999999L)); // Would trigger IllegalArgumentException: last modification time '9999999999' is too big ( > 8589934591 ). | |||
| assertTrue(toUploadWithModifiedDate.toFile().setLastModified(123456L)); // To have a stable, within ranges, value to compare with | |||
There was a problem hiding this comment.
This is basically rendering the test useless
This test ensures that the changes in 7a49cce
behave as expected.
It should fail in case the line
tar.setBigNumberMode(TarArchiveOutputStream.BIGNUMBER_POSIX);
is removed.
We need to find some other way to verify this.
There was a problem hiding this comment.
Open to suggestions, the test breaks on Java 21 but I don't have much context here ...
There was a problem hiding this comment.
Do you have any more context about how does the test break in 21?
In any case, it's better to disable this test for Java 21 only (@DisabledOnJre(JAVA_21))
There was a problem hiding this comment.
Agreed, going to disable the test instead, this is the outcome on Java 21:
java.lang.AssertionError:
Expecting
org.apache.commons.compress.archivers.tar.TarArchiveEntry@df31e1be
to have a property or a field named "lastModifiedTime" with value
2286-11-20T17:46:39.999Z
but value was:
2262-04-11T23:47:16.8547758Z
There was a problem hiding this comment.
Not sure if this is actually something misbehaving in that JDK
There was a problem hiding this comment.
This test has been failing for me locally as well for a while now.
| @@ -1095,7 +1095,7 @@ | |||
| <version>${maven.invoker.plugin.version}</version> | |||
| </plugin> | |||
| <plugin> | |||
| <groupId>org.jboss.jandex</groupId> | |||
| <groupId>io.smallrye</groupId> | |||
There was a problem hiding this comment.
Not sure if this might cause issues with Quarkus. We need to verify that the Jandex versions are compatible.
There was a problem hiding this comment.
org.jboss.jandex doesn't work with Java 21, and this is the solution I found in the wild, do we have any kind of nightly/snapshot tests we can use to verify the compatibility? Maybe @metacosm ?
There was a problem hiding this comment.
I'm not sure, maybe use jandex directly instead of the plugin? I think that would require adding empty beans.xml files, though…
There was a problem hiding this comment.
I just checked and Quarkus is using this Jandex distribution and version, so we should be fine:
- https://github.com/quarkusio/quarkus/blob/e3c7965ca331d8761897c52b56d5b4aa2c0fa114/bom/application/pom.xml#L23
- https://github.com/quarkusio/quarkus/blob/e3c7965ca331d8761897c52b56d5b4aa2c0fa114/bom/application/pom.xml#L4480-L4490
- https://github.com/quarkusio/quarkus/blob/dd0c2410286b82ec111be5e87f03024caff081a2/build-parent/pom.xml#L561-L565
|
Description
Supersedes closes #3612
Type of change
test, version modification, documentation, etc.)
Checklist