Use setup-java/setup-graalvm instead of setup-scala #91
Conversation
| @@ -476,7 +479,7 @@ ${indent(jobs.map(compileJob(_, sbt)).mkString("\n\n"), 1)} | |||
| githubWorkflowPublishTargetBranches := Seq(RefPredicate.Equals(Ref.Branch("main"))), | |||
| githubWorkflowPublishCond := None, | |||
|
|
|||
| githubWorkflowJavaVersions := Seq("adopt@1.8"), | |||
| githubWorkflowJavaVersions := Seq(JavaSpec.temurin("11")), | |||
There was a problem hiding this comment.
Isn't that a bit dangerous - publishing by default for Java 11?
There was a problem hiding this comment.
There's basically two possible dangers. One is that the classfiles have the wrong version header and are thus incompatible with <11, and the other is standard library stuff. In the former case, that only happens if you have Java sources mixed into your project and you aren't using the -target option. You're likely to be aware of the pitfalls if you're in that situation.
The standard library stuff is more complicated, but also much rarer. These are things like ByteBuffer#swap. They're hard to figure out in advance, but most people who are around these types of issues have some idea of what's going on.
At the very least, it's an easy fix downstream: you can just opt-in to Java 8. This change just makes Java 8 runtime an opt-in rather than an opt-out. I think it's important to apply some gentle pressure to the larger ecosystem to move forward. Java 8 is ancient at this point.
There was a problem hiding this comment.
But does this plugin set the -target option? 🤔
I agree it's time to move on but the reality is that production systems are slow in that regard.
I'm not sure what would be the trigger for the entire ecosystem to move forward, but we need something.
I'm just afraid that this isn't gonna provide sufficient motivation.
There was a problem hiding this comment.
I feel like the motivation has to be slow and subtle. Nothing else really makes sense or will work. What this change does is effectively lean into the idea that bending over backwards to support a deprecated JVM is the "unusual" thing to do, still possible but unusual in a small way.
For what it's worth, most production systems I see these days are on 11 or higher. It's very rare that I see something other than a library on 8.
There was a problem hiding this comment.
There is nothing subtle about publishing a library though - it's either on Java 8 or 11 and if it's on 11 you can't use 8 and that's it. If it's on 8 nobody that is using it would notice. I.e. it's more or less a binary choice for the ecosystem and at some point we will have to say it's time to bootstrap on Java 11. But it would be good to reach a widely supported decision to do so.
There was a problem hiding this comment.
Only if they have Java sources though. How wide of a cohort is that?
There was a problem hiding this comment.
Only if they have Java sources though.
Why? Doesn't the same apply to Scala sources as well? They also need to produce bytecode.
There was a problem hiding this comment.
The Scala compiler always targets Java 8 for bytecode output. If you do a quick publishLocal on anything that is pure Scala from Java 11 (or higher) and then grab it in ammonite on Java 8, it'll work perfectly.
There was a problem hiding this comment.
The Scala compiler always targets Java 8 for bytecode output. If you do a quick publishLocal on anything that is pure Scala from Java 11 (or higher) and then grab it in ammonite on Java 8, it'll work perfectly.
Ok nice 👍 Somehow I missed that, I guess I'm still confused about this stuff.
There was a problem hiding this comment.
The standard library stuff is more complicated, but also much rarer. These are things like ByteBuffer#swap. They're hard to figure out in advance, but most people who are around these types of issues have some idea of what's going on.
I'm not so sure about that.
Once something has already gone wrong (once a call to an 11+ or 17+ Java stdlib method has been used, and CI isn't set up to catch it) and the problem is noticed and reported, "most people" who do Scala OSS will know right away what happened. But by that point it's already too late; a library version has already accidentally been published that doesn't work on 8.
Perhaps it's reasonable — though bold — to make publish-on-11 the default as a way of encouraging people to drop 8, but I don't think "problems will be rare" is a good supporting argument.
Fixes #89