Skip to content

Java 11 testing #559

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
3 tasks done
adriaanm opened this issue Sep 18, 2018 · 31 comments
Closed
3 tasks done

Java 11 testing #559

adriaanm opened this issue Sep 18, 2018 · 31 comments

Comments

@adriaanm
Copy link
Contributor

adriaanm commented Sep 18, 2018

While we only officially support Java 8, we do some testing and provide some support for Java 11 (e.g. for JPMS module checks on 2.13).

Please 👍 this ticket if this is important to you, to give us a sense of how to prioritize this. This is also a good spot to leave other feedback, or report an issue (for detailed reports, please open an individual ticket -- this one is more a "works for me / or not").

As always, for questions / higher-level discussions, please use discourse.

@adriaanm adriaanm mentioned this issue Sep 18, 2018
45 tasks
@adriaanm
Copy link
Contributor Author

adriaanm commented Sep 18, 2018

For a detailed list of features from JDK >= 9, see

@SethTisue
Copy link
Member

ticket on JDK 11 for the Scala community build: scala/community-build#742.

(at the moment, the status is that I have run it on 11 locally, but we don't have a Jenkins job yet)

@m50d
Copy link

m50d commented Sep 19, 2018

Are you asking about JDK11 specifically or JDK9+ generally?

@adriaanm
Copy link
Contributor Author

To spend our (I mean the core team + all contributors) time efficiently in the face of Oracle's new 6-month cycle, I think our only realistic option is to test on LTS releases. We can discuss this as well, but I think it will be costly to track all intermediate ones.

@m50d
Copy link

m50d commented Sep 19, 2018

LTS-only sounds reasonable. From my selfish perspective I care that Scala gets tested on some 9+ version of the JDK (because I encounter issues that I believe are caused by 9's module changes), but it's not especially important to me whether that's 9, 10 or 11.

@markehammons
Copy link

@adriaanm I will probably be jumping to the new releases on a regular basis since all my software works with java-11 at this point. Is it fine if I report any bugs I encounter related to changes in the intermediate releases?

@adriaanm
Copy link
Contributor Author

adriaanm commented Sep 20, 2018 via email

@He-Pin
Copy link

He-Pin commented Sep 26, 2018

I think most people will jump directly to Java 11.

@da-liii
Copy link

da-liii commented Sep 26, 2018

Java 9 or 10 is Windows Vista.

@weiwen99
Copy link

We will upgrade to 11 from 8 as possible.

@kwinter
Copy link

kwinter commented Sep 26, 2018

The inclusion and open-sourcing of Flight Recorder in JDK 11 gives a lot of reason to jump to it (I'm counting the days until we can)

@plokhotnyuk
Copy link

plokhotnyuk commented Sep 27, 2018

IMHO most groundbreaking features of JDK 11 are:

  • Graal compiler which is able to speed Scala code in run-time greatly
  • ZGC which is enabler for usage of hardware scaled up with terabytes of RAM (especially for real-time services with huge in-memory caches and databases)

@xuwei-k
Copy link
Contributor

xuwei-k commented Sep 27, 2018

@adriaanm
Copy link
Contributor Author

Thank you, @xuwei-k! PRs merged :-)

@eed3si9n
Copy link
Member

eed3si9n commented Oct 4, 2018

Got Travis CI to run JDK 11 testing for 2.12.x in scala/scala#7311.

Here are some excerpts from https://travis-ci.org/scala/scala/jobs/437207406:

# Failed test paths (this command will update checkfiles)
partest --update-check \
  /home/travis/build/scala/scala/test/files/run/classfile-format-52.scala \
  /home/travis/build/scala/scala/test/files/run/getClassTest-new.scala \
  /home/travis/build/scala/scala/test/files/run/getClassTest-old.scala \
  /home/travis/build/scala/scala/test/files/run/lambda-serialization-gc.scala \
  /home/travis/build/scala/scala/test/files/run/numbereq.scala \
  /home/travis/build/scala/scala/test/files/run/reflection-fancy-java-classes \
  /home/travis/build/scala/scala/test/files/run/t1167.scala \
  /home/travis/build/scala/scala/test/files/run/t2318.scala \
  /home/travis/build/scala/scala/test/files/run/t3425b \
  /home/travis/build/scala/scala/test/files/run/t4148.scala \
  /home/travis/build/scala/scala/test/files/run/t6411a.scala \
  /home/travis/build/scala/scala/test/files/run/t6669.scala \
  /home/travis/build/scala/scala/test/files/run/t6827.scala \
  /home/travis/build/scala/scala/test/files/run/t7455 \
  /home/travis/build/scala/scala/test/files/run/t7741a \
  /home/travis/build/scala/scala/test/files/run/t8549.scala \
  /home/travis/build/scala/scala/test/files/run/t9030.scala \
  /home/travis/build/scala/scala/test/files/run/t9437b.scala \
  /home/travis/build/scala/scala/test/files/run/t9529

[error] Failed: Total 1889, Failed 19, Errors 0, Passed 1870

# Failed test paths (this command will update checkfiles)
partest --update-check \
  /home/travis/build/scala/scala/test/files/neg/checksensible.scala \
  /home/travis/build/scala/scala/test/files/neg/t9529.scala \
  /home/travis/build/scala/scala/test/files/jvm/annotations.scala \
  /home/travis/build/scala/scala/test/files/jvm/javaReflection \
  /home/travis/build/scala/scala/test/files/jvm/t3003 \
  /home/travis/build/scala/scala/test/files/jvm/throws-annot.scala \
  /home/travis/build/scala/scala/test/files/jvm/value-class-in-jannotation.scala

[error] Failed: Total 2535, Failed 7, Errors 0, Passed 2528

[error] Failed: Total 1366, Failed 6, Errors 0, Passed 1355, Skipped 5
[error] Failed tests:
[error]  scala.tools.nsc.backend.jvm.opt.MethodLevelOptsTest
[error]  scala.reflect.ClassOfTest
[error]  scala.lang.annotations.RunTest
[error]  scala.tools.nsc.backend.jvm.opt.BoxUnboxTest
[info] Updating {file:/home/travis/build/scala/scala/}scalacheck...

[error] Failed: Total 4, Failed 4, Errors 0, Passed 0
[error] Failed tests:
[error]  tools.test.osgi.reflection.toolbox.ReflectionToolBoxTest
[error]  tools.test.osgi.BasicTest
[error]  tools.test.osgi.reflection.basic.BasicReflectionTest
[error]  tools.test.osgi.libonly.BasicLibraryTest

[error] 7 of 12 test tasks failed:
[error] - junit/test
[error]   - junit/test:test failed: sbt.TestsFailedException: Tests unsuccessful
[error] - scalacheck/test
[error]   - scalacheck/test:test failed: sbt.TestsFailedException: Tests unsuccessful
[error] - partest run
[error]   - test/it:testOnly failed: sbt.TestsFailedException: Tests unsuccessful
[error] - partest pos neg jvm
[error]   - test/it:testOnly failed: sbt.TestsFailedException: Tests unsuccessful
[error] - osgiTestFelix/test
[error] - osgiTestEclipse/test
[error] - library/mimaReportBinaryIssues
[error]   - library/mimaReportBinaryIssues failed: java.lang.RuntimeException: scala-library: Binary compatibility check failed!

Not sure how much of it is superficial failure due to test and how much is legitimate issue, but basically 99% of the test cases are passing.

@ijuma
Copy link

ijuma commented Oct 28, 2018

Btw, ASM 7.0 is now out and it includes full non-experimental support for Java 11 and early support for Java 12.

@dbtsai
Copy link

dbtsai commented Nov 6, 2018

Hello, as majority of Spark users are still on Scala 2.11, do we have a plan to backport Java 11 work to Scala 2.11? Thanks!

@xuwei-k
Copy link
Contributor

xuwei-k commented Nov 6, 2018

Btw, ASM 7.0 is now out and it includes full non-experimental support for Java 11 and early support for Java 12.

scala/scala#7384

@adriaanm
Copy link
Contributor Author

adriaanm commented Nov 6, 2018

Scala 2.11 is EOL, sorry. It came out 4.5 years ago and we provided updates for 3.5 years, until 2.12 had been out for a year.

If someone is willing to sponsor the needed work (donating time ideally), we’re open to that.

@dbtsai
Copy link

dbtsai commented Nov 6, 2018

We'll discuss in Spark community, and see the possibility of moving to Scala 2.12 as default version in Spark 3.0. Thanks.

@JMLamodiere
Copy link

Hello @adriaanm ! I cannot find the page listing the official End Of Life date of scala versions. For instance, I've found something about 2.11 EOL in the release not of 2.11.11 , but cannot find the same information for 2.12 series. Could you please enlight me, and people in my situation ?
Thanks !

@adriaanm
Copy link
Contributor Author

adriaanm commented Jan 7, 2019

Our OSS EOL policy is not set in stone (we do offer more precise terms in our commercial support).

Generally, we try to maintain two versions prior to the current one in development, but it depends on our availability and that of community contributors, as well as the community's needs. Since our development cycle is between 18-24 months, this means we maintain a version for about 36 - 48 months after its initial .0 release.

@SethTisue
Copy link
Member

And more concretely, there will certainly be a 2.12.9 and it's likely there will be a few more 2.12.x releases after that, too, but with declining frequency.

2.12.5 and 2.12.7 had regressions that required prompt followup releases. if you leave those versions out, the pace recently has been:

  • 2.12.8: December 2018
  • 2.12.6: April 2018
  • 2.12.4: October 2017

so unless a specific pressing need arises, expecting subsequent 2.12.x releases to each take 6 months or more is a reasonable expectation.

@cosmir17
Copy link

cosmir17 commented May 1, 2019

Future Oracle Java 8 releases will be under a new license policy (commencing from 16th April 2019). https://java.com/en/download/release_notice.jsp
It's not going to be free for production use.

Is this going to change a direction which version of JVM that Lightbend is going to be more supportive for Scala lib development? For example, this may be another reason for Java 11 support? could be for 9 as well (#139)?
So far, Java 8 has been the primary platform.

@SethTisue
Copy link
Member

We expect that in OSS contexts everyone (including ourselves in the Scala org) will just use OpenJDK 8 instead of the Oracle one. It's fine.

When we test on 11, we are already doing it on OpenJDK, not Oracle's version.

re JDK 9, we aren't touching 9 or 10 anymore; see https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html

@cosmir17
Copy link

cosmir17 commented May 1, 2019

I see. I originally came from Java background so I didn't know it's safe to use OpenJDK(to run scala code) in production.
Glad to know that Lightbend made a decision to support specific versions of JVMs rather than every version.

ghost pushed a commit to camunda/camunda that referenced this issue Aug 12, 2019
2962: Fix Javadoc generation r=saig0 a=Zelldon

## Description


  After migration to Java 11 the generation of JavaDoc failed on develop.The following error was printed:

```java
[2019-08-09T16:16:31.038Z] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (default-cli) on project zeebe-build-tools: MavenReportException: Error while creating archive: 
[2019-08-09T16:16:31.038Z] [ERROR] Exit code: 1 - Picked up JAVA_TOOL_OPTIONS: -XX:+UseContainerSupport
[2019-08-09T16:16:31.038Z] [ERROR] 
[2019-08-09T16:16:31.038Z] [ERROR] javadoc: error - The code being documented uses modules but the packages defined in http://docs.oracle.com/javase/7/docs/api/ are in the unnamed module.
[2019-08-09T16:16:31.038Z] [ERROR] 
[2019-08-09T16:16:31.038Z] [ERROR] Command line was: /docker-java-home/bin/javadoc @options @packages
[2019-08-09T16:16:31.038Z] [ERROR] 
[2019-08-09T16:16:31.038Z] [ERROR] Refer to the generated Javadoc files in '/home/jenkins/workspace/zeebe-io_zeebe_develop/build-tools/target/apidocs' dir.
[2019-08-09T16:16:31.038Z] [ERROR] -> [Help 1]
```

Multiple things where problematic. As first we used an old java doc plugin, inherited by the camunda release parent and the java version was not set correctly.

After fixing this, some other modules had still a problem with generating java doc.
 * `json-el`:
   * Scala currently do not support 100% Java 11.
      See:
        * https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html
        * scala/scala-dev#559
  * `gateway-protocol-impl` 
    * is compiled with 8, but if we execute java doc with 11 we get the error that javax was not found. I will create an issue to investigate this.
  * `protocol-assert`:
    * generated code seems to have some problems with the javadoc. I create an issue for this.

To verify the changes you can run:

```bash
 mvn -B -T1C generate-sources source:jar javadoc:jar clean verify -DskipTests
```

#

Co-authored-by: Christopher Zell <[email protected]>
@toktarev

This comment has been minimized.

@dwijnand

This comment has been minimized.

@toktarev

This comment has been minimized.

@SethTisue
Copy link
Member

the last piece of this landed at scala/scala#9579

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests