Update Scala versions

[mdedetrich]

This PR updates the Scala versions of Akka.

References: #6

[nvollmar]

lgtm

[mdedetrich]

Currently blocked by https://discord.com/channels/632150470000902164/632150470000902166/1087726290561400832

[mdedetrich]

So one thing to note on this PR is that the workaround with using -target described in akka/akka#27079 has been removed. because -target is now deprecated in the latest versions of Scala 2.12/Scala 2.13 and more importantly -release has since been fixed so this specific workaround is not necessary anymore. The original problem with -release was that it didn't properly link the JDK 8 runtime library however this has since been solved. As stated in https://github.com/apache/incubator-pekko/blob/main/project/JdkOptions.scala#L60-L67 this can be verified, and I can at least confirm on my end that -release has indeed been fixed, i.e.

<@incubator-pekko/r/t/s/c/o/a/p/r/artery>-<⎇ update-scala-versions>-<±>-<*>-2-> javap -c EnvelopeBuffer.class | grep "java/nio/ByteBuffer.clear:()Ljava/nio/Buffer"
       9: invokevirtual #121                // Method java/nio/ByteBuffer.clear:()Ljava/nio/Buffer;

works for both Scala 2.12 and Scala 2.13.

Aside from that the newer versions of Scala 2.12 and Scala 2.13 have improved/added/updated various warnings which explains the the various changes to @nowarn annotation.

[mdedetrich]

@raboof @He-Pin @jrudolph Since you are more familiar with the internals do you want to have a look if there is anything out of place on this PR? #258 (comment) is of importance. Also https://discord.com/channels/632150470000902164/632150470000902166/1087731784990605402 is relevant here.

[He-Pin]

I was submitted a pr in akka/akka for this
akka/akka#31648
akka/akka#31652

and for compiling scala with 3.2 & 3.1 akka/akka#31578

@mdedetrich Would you like to check if there is something missing?

[mdedetrich]

@He-Pin I checked the relevant PR's and it doesn't appear that I have missed anything (the Scala 3.2 one I ignored because thats a separate concern). There can be further simplification but would make sense to do this in context of Scala 3.

[som-snytt]

This enables no lints. -Xlint -Xlint:-infer-any or -Xlint:-infer-any,_ with underscore to mean all. (Not sure if that was intended here.)

[mdedetrich]

Thanks, fixing now

[jrudolph]

The removal of -javabootclasspath breaks building with JDK 11 for me, also reproducible in Docker containers. I know I investigated before, if it could be removed and I ran into issues before.

I wonder how it works on Github CI and other machines.

[raboof]

interesting, seems to work on my machine - what does it break on for you?

[pjfanning]

@jrudolph we have a release candidate (1.0.1-RC1) at https://repository.apache.org/content/groups/staging/org/apache/pekko/

Would you be able to see if there is anything missing in the jars?

The RCs have been built on my Mac. I use sdkman to manage my JDK installs.

The CI builds all seem fine.

I have no objection to putting back the javabootclasspath if it makes the build work for you. In the short term, I would be worried that there is something up with RC and the 1.0.0 release.

[som-snytt]

I haven't looked at this conversation, but FYI there was a bug fix to prefer javabootclasspath, someone needed to compile against a specific version of rt.jar. This PR scala/scala#10336

[pjfanning]

The RC1 pekko-remote jar: I ran the javap -c on the EnvelopeBuffer class and got

      9: invokevirtual #121                // Method java/nio/ByteBuffer.clear:()Ljava/nio/Buffer;

Which I think means that the RC1 jar is not affected by Issue #27079

[pjfanning]

I haven't looked at this conversation, but FYI there was a bug fix to prefer javabootclasspath, someone needed to compile against a specific version of rt.jar. This PR scala/scala#10336

Thanks @som-snytt - the Pekko build uses Scala 2.13.11 so we might be benefitting from the scala/scala#10336 change.