Stale ./sbt script (included by Example Code Service?) doesn't work with JDK 11

[aed-project]

To recreate problem execute:
./sbt
The sbt version is 1.3.10

build.sbt:

maintainer := "your.name@company.org"
lazy val root = (project in file("."))
  .enablePlugins(PlayScala)
  .settings(
    name := """agents""",
    version := "live",
    scalaVersion := "2.13.2",
    libraryDependencies ++= Seq(
      guice
    ),
    scalacOptions ++= Seq(
      "-feature",
      "-deprecation",
      "-Xfatal-warnings" )
  )

problem

sbt will not start when Java 11 is the installed Java.
When executing ./sbt from inside a Play Framework 2.8 application directory
there is the following error message with program exiting.

The java installation you have is not up to date
requires at least version 1.6+, you have
version 11.0.7
Please go to http://www.java.com/getjava/ and download
a valid Java Runtime and install before running .

expectation

Java 11 is certainly not out of date. I expect sbt to recognize the Java version of 11.0.7
as being later than version 1.6 and allow sbt to start with Java 11.

notes

I downloaded sbt and looked at source; specifically:
sbt-develop/main/src/main/scala/sbt/internal/CrossJava.scala
This code uses regular expression evaluation to determine validity of the Java version.
The approach taken assumes the format of the version will remain the same in the future.
This is a very brittle approach and has caused a serious problem.
The way this code should be written is to put every valid Java version label into a text file and
have them read into a table. Take the java version and look for a hit in the table. This technique
is impervious to format change and because the valid Java version labels are in a text file
it is possible to update with version addition or removal without rebuilding the whole project.

[eatkins]

Thanks for submitting this issue. I agree that 11.0.7 should be recognized as a valid java version. My understanding is that the java version number format is well specified but was changed with jdk 10: https://docs.oracle.com/en/java/javase/12/install/version-string-format.html. It seems like CrossJava is not correctly parsing all versions >= 10.0.0.

The way this code should be written is to put every valid Java version label into a text file and
have them read into a table.

"Should be" is a phrase that should be avoided in a bug report without a corresponding patch, which we would be happy to evaluate. Using that kind of loaded language is abrasive and, if the goal is to get the sbt maintainers to fix the issue, is counterproductive. sbt is a community effort and anything that isn't working correctly should be fixed by the community.

I also am struggling to understand how a version table wouldn't be even more fragile than the existing solution (with a ptach to fix the bug). New java versions are released by different vendors all the time. Keeping such a table up to date does not seem feasible without external help. Even if it were, where would the text file live? As you point out, it couldn't be a resource of sbt itself because that would mean that every time a new java version was released, we'd have to release a new version of sbt to support it. If there was a java version repository, then sure sbt could reach out to it. Who would maintain such a repository? What happens if it is unavailable over the network?

[eed3si9n]

Thanks for the report. I created Notes section for reporters to take a stab at implementation analysis, so I'm personally ok since the steps and problem section are opinion-free :)

Given that the error message you're seeing is coming from the bash script https://github.com/sbt/sbt-launcher-package/blob/25c1b96dae6d328a0645068f63e4fde61b89674b/src/universal/bin/sbt#L318-L326, I don't think has anything to do with CrossJava.scala.

There's been multiple PRs addressing JDK 10 or 11 for the sbt script in 2017~2018 (sbt/sbt-launcher-package#209, sbt/sbt-launcher-package#215, sbt/sbt-launcher-package#225). On Travis CI we test the scripts using both JDK 8 and 11 (https://github.com/sbt/sbt-launcher-package/blob/25c1b96dae6d328a0645068f63e4fde61b89674b/.travis.yml#L51-L63). The question is how you got the ./sbt script, and how fresh it is.

(There seems to be different ways of installing sbt script coming out every other week, so it could be confusing.)

[eed3si9n]

I've been thinking how this could be happening and realized that the example projects created by Play includes a stale version of sbt - playframework/playframework#10315

[eed3si9n]

I'm closing this in favor of playframework/playframework#10315