fix GHA problems

[mzuehlke]

• make sure ids don't contain DOTs
• openj9 is adopt-openj9 https://github.com/actions/setup-java#supported-distributions

closes: #557

[durban]

Thanks, this makes sense.

According to the note below the table you linked, "It is highly recommended to migrate workflows from adopt and adopt-openj9, to temurin and semeru respectively...". Would it make sense to use "semeru" instead of "adopt-openj9"?

[mzuehlke]

According to the note below the table you linked, "It is highly recommended to migrate workflows from adopt and adopt-openj9, to temurin and semeru respectively...". Would it make sense to use "semeru" instead of "adopt-openj9"?

Looking at the table I would suggest to:

• deprecate Distribution.OpenJ9
• add Distribution.Semuru
• add Distribution. Microsoft

WDYT ?

[armanbilge]

Thanks, I agree. I also wonder if we should deprecate the legacy way of specifying Graal versions.

[mzuehlke]

Thanks, I agree. I also wonder if we should deprecate the legacy way of specifying Graal versions.

With legacy, you mean this one, right:

final case class GraalVM(version: String) extends Distribution(version)

[durban]

• I'd be fine with Distribution.OpenJ9 simply using semeru (as far as I understand, they're practically the same). But deprecating and creating Distribution.Semeru is also fine.
• Adding microsoft: sure, why not.
• Deprecating legacy graal versioning: as far as it's possible to use it, I don't mind.

To avoid again having non-working JavaSpecs, it might make sense to add all these to the CI (unless of course having too much is a concern).

[armanbilge]

• I'd be fine with Distribution.OpenJ9 simply using semeru (as far as I understand, they're practically the same)

Feels a bit disingenuous. After all, upstream could have chosen to do that, but they didn't.

• Deprecating legacy graal versioning: as far as it's possible to use it, I don't mind.

Well, maybe I take this back. Might be too early to deprecate this, seems the old versions may still be supported for a while.

To avoid again having non-working JavaSpecs, it might make sense to add all these to the CI (unless of course having too much is a concern).

Yeah, annoying to bloat up the CI, but I don't disagree. Sorry for the regressions.

[armanbilge]

Added them to CI and everything that is here looks good. We can follow-up with additional distributions/deprecations etc. Thanks a bunch!

[mzuehlke]

Added them to CI and everything that is here looks good. We can follow-up with additional distributions/deprecations etc. Thanks a bunch!

Thanks for finishing this one.