Support emitting Java 9 bytecode by adding "-target:9" #8060

hrhino · 2019-05-15T01:08:38Z

A resurrection of @mkurz's #6146 (in the sixes!) that drops support for 1.7 and under, and gives the option of -target:jvm-9 for symmetry with -target:jvm-1.8, but prefers -target:9 (as a combination of @retronym's and @SethTisue's suggestions on that PR). Well, it still prefers -target:jvm-1.8 over either, but it can be persuaded to change its mind.

The sole effect of this flag is to emit bytecode that breaks on Java 8, which @SethTisue points out would be a useful feature. The hope is that it can be used also to enable various features which are impossible on versions later than 8, if we so desire.

I'm prepared to accept criticism, pushback, and outright insults based on at least these bases:

~~should we also have -target:10 and -target:11?~~
- ~~should we additionally also have -target:jvm-10 &c.?~~
should we not have the jvm- variant at all?
should I have kept the previous versions? (I hope not!)
is this a good idea at all?

retronym · 2019-05-15T02:21:35Z

jvm- is something of a historical artifact of the time there was also msil- (the .NET backend). IMO we should align with javac now, and primarily use -target:9 etc. If it's easy to do, we can still support jvm- prefixed targets for backwards compat.

retronym · 2019-05-15T02:37:16Z

src/compiler/scala/tools/nsc/settings/StandardScalaSettings.scala

@@ -45,12 +47,15 @@ trait StandardScalaSettings {
  val nowarn =         BooleanSetting ("-nowarn", "Generate no warnings.") withAbbreviation "--no-warnings"
  val optimise:        BooleanSetting // depends on post hook which mutates other settings
  val print =          BooleanSetting ("-print", "Print program with Scala-specific features removed.") withAbbreviation "--print"
-  val target =         ChoiceSettingForcedDefault ("-target", "target", "Target platform for object files. All JVM 1.5 - 1.7 targets are deprecated.",
-                          List("jvm-1.5", "jvm-1.6", "jvm-1.7", "jvm-1.8"), "jvm-1.8") withAbbreviation "--target"
+  val target =         ChoiceSetting  ("-target", "target", "Target platform for object files.", List("jvm-1.8", "jvm-9", "9"), "jvm-1.8") withPostSetHook fixupTarget _ withAbbreviation "--target"


How abuot we just advertise "1.8", "9", ... here, and rig up this setting to strip off the jvm- part before the contains call in ChoiceSetting.

case List(x) if choices contains x => value = x ; SomeOfNil

= ChoiceSetting ("-target", "target", "Target platform for object files.", List("jvm-1.8", "jvm-9", "9"), "jvm-1.8").withPostSetHook(fixupTarget).withPreSetHook(_.stripPrefix("jvm-")).withAbbreviation("--target")

(where withPreSetHook is a new method on ChoiceSetting)

Adding a method to ChoiceSetting from this class is apparently non-trivial.

retronym · 2019-05-15T02:40:16Z

src/compiler/scala/tools/nsc/backend/jvm/analysis/BackendUtils.scala

@@ -74,6 +74,7 @@ abstract class BackendUtils extends PerRunInit {

  lazy val classfileVersion: LazyVar[Int] = perRunLazy(this)(compilerSettings.target match {
    case "jvm-1.8" => asm.Opcodes.V1_8
+    case "9"       => asm.Opcodes.V9


I'd extend this at least to 11.

hrhino · 2019-06-01T02:27:25Z

As the (new) commit message says, "I got annoyed with all of the abstract types and such involved in the settings cake with the stated goal of enabling an immutable Settings object which is nearly a decade in the making. It's enough to make me lose a bit of faith, and therefore I've trimmed down the amount of abstraction going on here."

retronym · 2019-06-03T02:17:54Z

src/compiler/scala/tools/nsc/settings/AbsScalaSettings.scala

-
-import scala.language.higherKinds
-
-trait AbsScalaSettings {


retronym · 2019-06-12T07:47:14Z

src/compiler/scala/tools/nsc/settings/StandardScalaSettings.scala

  val unchecked =      BooleanSetting ("-unchecked", "Enable additional warnings where generated code depends on assumptions.") withAbbreviation "--unchecked"
  val uniqid =         BooleanSetting ("-uniqid", "Uniquely tag all identifiers in debugging output.") withAbbreviation "--unique-id"
  val usejavacp =      BooleanSetting ("-usejavacp", "Utilize the java.class.path in classpath resolution.") withAbbreviation "--use-java-class-path"
  val usemanifestcp =  BooleanSetting ("-usemanifestcp", "Utilize the manifest in classpath resolution.") withAbbreviation "--use-manifest-class-path"
  val verbose =        BooleanSetting ("-verbose", "Output messages about what the compiler is doing.") withAbbreviation "--verbose"
  val version =        BooleanSetting ("-version", "Print product version and exit.") withAbbreviation "--version"
+
+  final val MinTargetVersion = 8
+  final val MaxTargetVersion = 12 // this one goes to twelve


Let's make these non-constants in case some separately compiled client code wanted to depend on updated values.

retronym · 2019-06-12T07:50:42Z

project/ScalaOptionParser.scala

@@ -106,7 +106,7 @@ object ScalaOptionParser {
    "-Ymacro-expand" -> List("discard", "none"),
    "-Yresolve-term-conflict" -> List("error", "object", "package"),
    "-g" -> List("line", "none", "notailcails", "source", "vars"),
-    "-target" -> List("jvm-1.5", "jvm-1.6", "jvm-1.7", "jvm-1.8"))
+    "-target" -> List("jvm-1.8", "jvm-9", "9"))


Needs to go up to 12 as well.

It would be great if we could resurrect https://github.com/scala/scala-tool-support/blob/master/bash-completion/src/main/scala/BashCompletion.scala to dynamically generate the completion data for Bash and for sbt scalac ... as well.

Just remembered we now have sbt generateDocsData which generates compiler-options.yml containing all the data we would need. So the "it would be great" thing would now to be that data into the our parser for sbt scalac and to transform that data into a bash completion script.

retronym

Avoid constants for things that will change
Update SBT option parser to go up to 12.

I got annoyed with all of the abstract types and such involved in the settings cake with the stated goal of enabling an immutable `Settings` object which is nearly a decade in the making. It's enough to make me lose a bit of faith, and therefore I've trimmed down the amount of abstraction going on here. I'm sure that if we ever do get around to that refactor, this won't be that hard to reinstate. Co-Authored-By: Matthias Kurz <m.kurz@irregular.at>

mr-git · 2019-09-18T13:47:55Z

and we have 13 already now, at time, when 2.13.1 gets released... and 14 (LTS) is coming in 6 month...
Will Scala support compilation at 13, 14 (LTS) (15, 16, 17 (LTS)) in 2.13.2+?

SethTisue · 2019-09-30T19:34:13Z

and we have 13 already now, at time, when 2.13.1 gets released... and 14 (LTS) is coming in 6 month...

Will Scala support compilation at 13, 14 (LTS) (15, 16, 17 (LTS)) in 2.13.2+?

a few relevant tickets:

pull requests in this area are welcome

lrytz · 2019-10-10T09:43:06Z

In a recent internal discussion, @dwijnand clarified that Java 14 is not LTS, the next LTS release will be 17:

https://www.oracle.com/technetwork/java/java-se-support-roadmap.html says "Oracle will designate a release, every three years, as a Long-Term-Support (LTS) release", so every 6th release, given their 6 months cadence
https://en.wikipedia.org/wiki/Java_version_history

scala-jenkins added this to the 2.13.1 milestone May 15, 2019

hrhino force-pushed the topic/jvm-9 branch from 67c3008 to e012b79 Compare May 15, 2019 01:23

hrhino requested review from retronym, adriaanm and SethTisue May 15, 2019 01:36

retronym reviewed May 15, 2019

View reviewed changes

hrhino force-pushed the topic/jvm-9 branch 2 times, most recently from 8ffdb99 to 6093cff Compare June 1, 2019 02:24

retronym reviewed Jun 3, 2019

View reviewed changes

src/compiler/scala/tools/nsc/settings/AbsScalaSettings.scala

import scala.language.higherKinds

trait AbsScalaSettings {

Copy link

Member

retronym Jun 3, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💯

retronym reviewed Jun 12, 2019

View reviewed changes

SethTisue added the release-notes label Jun 18, 2019

retronym requested changes Jun 19, 2019

View reviewed changes

hrhino force-pushed the topic/jvm-9 branch from 6093cff to a5efdc9 Compare June 25, 2019 01:35

hrhino requested a review from retronym June 27, 2019 23:59

retronym approved these changes Jun 28, 2019

View reviewed changes

retronym merged commit c5431b0 into scala:2.13.x Jun 28, 2019

som-snytt mentioned this pull request Sep 18, 2019

Make the compiler doc tool work on 2.13 scala/bug#11642

Open

rshkv mentioned this pull request Oct 29, 2020

Use old version-string scheme for Scala compiler target palantir/gradle-baseline#1528

Merged

som-snytt mentioned this pull request Feb 19, 2022

[backport] Make -target support JDK 8 through 19 (and deprecate 5 through 7) #9916

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support emitting Java 9 bytecode by adding "-target:9" #8060

Support emitting Java 9 bytecode by adding "-target:9" #8060

hrhino commented May 15, 2019 •

edited

Loading

retronym commented May 15, 2019

retronym May 15, 2019 •

edited

Loading

hrhino Jun 1, 2019 •

edited

Loading

retronym May 15, 2019

hrhino commented Jun 1, 2019

retronym Jun 3, 2019

retronym Jun 12, 2019

retronym Jun 12, 2019

retronym Jun 12, 2019

retronym left a comment

mr-git commented Sep 18, 2019

SethTisue commented Sep 30, 2019

lrytz commented Oct 10, 2019

Support emitting Java 9 bytecode by adding "-target:9" #8060

Support emitting Java 9 bytecode by adding "-target:9" #8060

Conversation

hrhino commented May 15, 2019 • edited Loading

retronym commented May 15, 2019

retronym May 15, 2019 • edited Loading

Choose a reason for hiding this comment

hrhino Jun 1, 2019 • edited Loading

Choose a reason for hiding this comment

retronym May 15, 2019

Choose a reason for hiding this comment

hrhino commented Jun 1, 2019

retronym Jun 3, 2019

Choose a reason for hiding this comment

retronym Jun 12, 2019

Choose a reason for hiding this comment

retronym Jun 12, 2019

Choose a reason for hiding this comment

retronym Jun 12, 2019

Choose a reason for hiding this comment

retronym left a comment

Choose a reason for hiding this comment

mr-git commented Sep 18, 2019

SethTisue commented Sep 30, 2019

lrytz commented Oct 10, 2019

hrhino commented May 15, 2019 •

edited

Loading

retronym May 15, 2019 •

edited

Loading

hrhino Jun 1, 2019 •

edited

Loading