https://kotlinlang.org logo
Join Slack
Powered by
I'm wondering why kotest requires Java 11+ startin...
# kotest
p
I'm wondering why kotest requires Java 11+ starting 6.0. I found the PR but there's no explanation: https://github.com/kotest/kotest/pull/4749. I'm asking because there's demand to use my library where I use kotest still with Java 8, and setting up some kind of dual building (releasing for 8, testing with 11) could make things complicated, so I'm just curious about the update to 11 on kotest's side. I realize that JDK 8 has been EOL for like 3 years, but well, it's still running somewhere out there 🤷
a
v
Why do people keep saying the non-sense that Java 8 is end of life? The times when Oracle dictated when a Java version is end of life are long gone, Oracle is just one of many distribution providers. The latest Temurin 8 Hotfix for example was released one week ago and it will be maintained at least until November 2026.
Btw building with 8 testing with 11 should be quite trivial using JVM toolchains, setting 8 as target and then in the test task 11 for execution.
p
Looks like the "11 for tests" approach is emerging as the best option
👌 1
b
not so trivial once Android and composite build come into play. We uses dedicated android targets, even for libraries that don't use any Android APIs just to remain at Java 1.8 for Android and use Java 17 for the JVM. For Android tests, we then bump the target to 17 again, so testing is smooth. Not pretty though and not manageable at scale unless you use a dedicated gradle conventions plugin
p
I think it would be useful to include a short snippet/recipe in kotest's docs on how to build for production for Java 8, and run tests with Java 11. Multiple projects may be impacted by this change in kotest, and kotest could somehow compensate the change by extending a helping hand in a form of docs
For now I've got this config that does what I want, happy to discuss pros/cons and if we collectively arrive at some recommended setup, I'm happy to contribute to the kotest's docs: https://github.com/krzema12/snakeyaml-engine-kmp/pull/489
😱 1
b
Your apprach smells of footgun to me. Why not use a lower JVM target globally for all compilations and only explicitly bump the target for test compilation? This way you'd know that you're only using things that actually exists for all main sources and you can still use kotest or anything else that might come in handy for testing. It's a bit fiddly, but it works. We've been doing it like that for our Android targets (see here) and have not once run into issues and the compiler complains if we use anything that is not available in Java 1.8 (which we still use for some projects targeting Android)
💯 1
p
@Bernd Prünster does your code bump the target also for compiling the code under test (think: 
main/src
), not just the tests' code (think: 
test/src
)? see my notes here and let me know if we're on the same page here
b
The way I understand how the KGP works is that you have different compile tasks / compilations for main and test compilations. test compilations depend on main compilations, yo when you only bump the test compilationds JVM version, main sources are still compiled targeting, e.g. Java 8. once that is done, test sources are compiled with never java versions. Now if my understanding is correct, the answer is no. my approach does not bump the target for main sources, not even when testing
you can easily play around with that though: set java 8 globally and don't bump anything. add some fancy java 11 stuff to your test sources and it will naturally fail. then do the (admittedly clumsy) filtering by compilation name for tests, where you bump to java 11 and it should start working. if you then add the java 11 stuff to main sources it should fail again
p
So far I've been assuming that I need to compile also the code under test (not just tests) with target 11 to make kotest work, but maybe indeed compiling just the tests will be enough. It's not obvious to me because the tests depend on the code under test. I need to play with it a bit more, thanks
b
But those are separate compilations
p
Yeah, but I thought that the tests need to consume production code compiled with 11 as target as well
And if it's not true, it should indeed simplify the whole problem
👍 1
v
That would be extremely strange and unexpected
p
@Bernd Prünster @Vampire ok, I think I've got to the bottom of this, here's a fixed PR: Use Java 11 for compiling and running tests, could you take a look? I also had to configure the 11 version in two extra places (compiling Java tests and launcher for the tests)
v
You only need to compile the test code with Java 11 because Kotest inline functions are inlined into that code
👍 1
The production code is just like any other library and it should be irrelevant with what version <= 11 it is compiled
So like I said from the start, just make the test code Java 11 and all should be fine. :-)
p
online -> inlined, right? yeah, I've just understood it earlier today and it all started to make sense, and the above elegant solution appeared
I think the PR is doing just this? I'm not touching how production code is compiled
if there's something wrong with the PR, can you add a comment in GitHub so that I have context what's wrong?
b
I just skimmed through it but it looks good!
thank you color 1
v
Yes, that reads much better and like what I suggested 😄
thank you color 1
6 Views
Open in Slack
PreviousNext
Powered by