Update to Java 17 #4307
Update to Java 17 #4307
Conversation
| @@ -31,7 +32,7 @@ class BlazegraphSlowQueryStoreSuite | |||
| SparqlQuery(""), | |||
| failed = true, | |||
| 1.second, | |||
| Instant.now(), | |||
| Instant.now().truncatedTo(ChronoUnit.MILLIS), | |||
There was a problem hiding this comment.
[The clock used by
Instant.now()] is based on the best available system clock. This may use System.currentTimeMillis(), or a higher resolution clock if one is available.
https://docs.oracle.com/javase/8/docs/api/java/time/Clock.html#systemUTC--
Based on this perhaps calls to Instant.now() should be made with a specific clock, especially outside of tests.
There was a problem hiding this comment.
I think in production code we are safe, as we should never be calling Instant.now() directly. In tests it's more annoying to have to use a clock.
One possible solution is to be a bit more relaxed in tests. I know that we use a fixed clock and check exact timestamps, but an alternative approach is to use a normal clock be a little more flexible. That is probably too big a change though
Perhaps there is some sort of typeclass equality that could rescue us..?
| - name: Setup JDK | ||
| uses: actions/setup-java@v3 | ||
| with: | ||
| distribution: 'temurin' | ||
| java-version: '17' | ||
| check-latest: true |
There was a problem hiding this comment.
I don't think you necessarily have to do it in this PR, but here is something interesting: https://github.com/marketplace/actions/setup-java-jdk#caching-sbt-dependencies
There was a problem hiding this comment.
I have tried it but for some reason it takes ages to recover the cache. Example: https://github.com/BlueBrain/nexus/actions/runs/6318630985/job/17158027837 It takes 2m45 to fetch the cache but doesn't speed up the actual build/tests 🤔
There was a problem hiding this comment.
Btw there is caching added to the release and snapshot pipelines to try it out. My suspicion is that it should work ok on the cloud runners. If it is also slow I will remove it.
Closes #3645