Card-Forge
CI: Test on all current Java LTS versions (8, 11 ,17, and 21)
Tests on JDK 17 and 21 are optional (since they currently fail).
The very existence of these tests will increase the awareness on the importance of code compatibility with newer Java versions, thus enabling future transitions to be implemented gradually.
Making the code run on JDK 11 took a lot of hacking. This will reduce the effort for eventual future transitions.
Looks like it's TestNG causing problems? Would they even offer a version that can support 4 JDK simultaneously... 🤔 Otherwise I think seeing all PR fail (partly) is too noisy and confusing for contributors.
Looks like it's TestNG causing problems? Would they even offer a version that can support 4 JDK simultaneously... 🤔 Otherwise I think seeing all PR fail (partly) is too noisy and confusing for contributors.
Well, it seems this PR is already achieving its aim of raising awareness on things to improve... What about accepting this pain as an incentive to
- deprecate TestNG?, and
- move existing TestNG tests to JUnit 5?
Like this PR, for example: https://github.com/Card-Forge/forge/pull/4942
Don't you need to run your test with add-opens?
https://github.com/Card-Forge/forge/blob/152ad0b0afe33502ad4cdb5eacb20cb9b3b196f1/forge-gui-desktop/src/main/config/forge.sh#L44-L52
Don't you need to run your test with add-opens?
Wouldn't this hide the fact that the current code does not compile with JDK 17+?
I think that it is important to be explicitly aware of this... (aka "Bring the pain forward") https://medium.com/continuousdelivery/if-it-hurts-do-it-more-often-f5a00cc12ffa
If we are not even aware of this problem, then no one will see an incentive to fix it...
As I said above, I think that just this awareness in itself makes merging this worth it...
Wouldn't this hide the fact that the current code does not compile with JDK 17+?
it would. if using the right ADD-OPENS parameters
This PR has not been updated in a while nad has been marked on stale. Stale PRs will be auto closed
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Well, being explicit about that the code won't compile unless that hack is used is part of the "awareness raising" rationale I mentioned when I first opened this PR...
I mean, the first step to solve a problem is to accept its existence, right? https://jhall.io/archive/2022/06/11/if-it-hurts-do-it-more/
I mean, the first step to solve a problem is to accept its existence, right? https://jhall.io/archive/2022/06/11/if-it-hurts-do-it-more/
The "pain" you are referring too is JAVA 17+ messing up our Code we depend on it, and can't really update
Here's my suggestion for this PR. Instead of having these failing (optional) tests run every single PR which is a lot of noise and Github Actions CPU cycles. And potentially very noisy for new people who don't understand that this is expected behavior, why don't we associate this change only during release builds that way we can keep it in mind if there's a future way to avoid add-opens, but its not just noise for the sake of noise.