Closed curiousleo closed 3 years ago
@curiousleo: My only concern with the suggested changes would be if they enforce an upgrade in the end-users' Java™ version? We need to carefully consider if we loose users of SBSCL by enforcing higher Java versions or if it is backward compatible? Which would be the minimal Java version that can still be used after these changes?
Fair point!
Changing jdk.version
in pom.xml
and then running mvn compile
shows that master
as of 7d9548820719b587f36c54157537700afd40dbec
pom.xml
and what runs in CI)This PR also builds against JDK 8 (if not, it would have failed CI). So there's no regression in terms of which JDK versions SBSCL can build against, compatibility is unchanged.
@curiousleo: My only concern with the suggested changes would be if they enforce an upgrade in the end-users' Java™ version? We need to carefully consider if we loose users of SBSCL by enforcing higher Java versions or if it is backward compatible? Which would be the minimal Java version that can still be used after these changes?
Fair point!
Changing
jdk.version
inpom.xml
and then runningmvn compile
shows thatmaster
as of 7d95488
- Fails to build against JDK 6: "diamond operator is not supported"
- Fails to build against JDK 7: "lambda expressions are not supported"
- Successfully builds against JDK 8 (that's what the default is in
pom.xml
and what runs in CI)This PR also builds against JDK 8 (if not, it would have failed CI). So there's no regression in terms of which JDK versions SBSCL can build against, compatibility is unchanged.
Ok, I think, Java 8 is nearly 7 years old and, therefore, a requirement we can assume users to have installed by now.
A few automated refactors. The commits are self-contained.
Feel free to ignore - some of these are stylistic questions about which opinions can differ!