Test Day:2018-09-26:java 8, 10 and 11 testday

Can't make the date? If you come to this page before or after the test day is completed, your testing is still valuable, and you can use the information on this page to test, file any bugs you find at Bugzilla, and add your results to the results section. If this page is more than a month old when you arrive here, please check the current schedule and see if a similar but more recent Test Day is planned or has already happened.

Today's instalment of Fedora Test Day will focus on OpenJDK 11 and OpenJDK 10. Currently we have java-1.8.0-openjdk as main JDK in Fedora. It accompanied java-1.7.0-openjdk as JRE for a year, and replaced it in buildroot in F21. Similarly, as did java-1.7.0-openjdk to java-1.6.0-openjdk in F16 as parallel JRE and replaced it in F17 in build root and main JDK.
However, today the situation is more complicated. Oracle changed release process, see OpenJDK 11 summary and OpenJDK 10 summary, so currently, in F27 and up, you have java-1.8.0-openjdk as main JDK, java-openjdk as rolling release of STS JDK 10, and java-11-openjdk as techpreview of future LTS JDK. Javaws is provided in another package - icedtea-web

Most crucial is, that JDK10 and JDK11, unlike JDK8, are modular, so many java applications will cease to work.

This is not crucial part of the testing, but to have an matrix of most common failures would be interesting

The following cast of characters will be available testing, workarounds, bug fixes, and general discussion. In case of problem related to test day organization/wiki/whatever, please reach out to sumantrom.

-debug or -slowdebug packages are not for reasonable use. They are for people debugging JDK iself. This testcase is not covering them. Feel free to try to install them, and to switch them, also some apps should run in them (although terribly slowly) so if you face some issues with them, it is most likely not an issue.

sudo alternatives --config $MASTER
# will select the tooling acocrding by masters from above
# except programs on PATH, also direcotries in /usr/lib/jvm are shufled. Please observe!
alternatives --display $MASTER
# will show current setup for given master
### headless JRE ###
# if your application do not need X (GUI) operate with ...-headless subpackage only in above examples
# if you need javac, operate with ...-devel subpackage in above examples
# if you need javadoc or sources, operate with ...-src, -javadoc and javadoc-zip subpackage in above examples
########################################################
# There are *many* jdk packages and countless subpackages
########################################################
no | sudo dnf install "java*openjdk*"
dnf search "java*openjdk*"
# note for f28 - jdk9 is no longer supported, and is there only because jdk10 was not alive in time of f28 release
# on f29 you should NOT see jdk9 appear
# Please try to install and use various combinations. This is quite crucial part of this testday.
# is the combination working and you can switch?
# can you switch installtaions
# are slaves as expected?
# is /etc/java affecting correct jdk and so on....

# jdk8 and jdk11 have new garabge collector (on x86_64 and aarch64)
# you can use it via:
java -XX:+UseShenandoahGC ohter_params_as_ususal
# or set it up globally:
export JAVA_TOOL_OPTIONS="-XX:+UseShenandoahGC $JAVA_TOOL_OPTIONS"
# are you applications working with Shenandoah?
# are they working better?

If you run out of test cases, congratulations! But that's not the end! You can still help out by playing around with the various installs uninstalls parallel isntalls jre/jdk switching... in whatever ways you can think of: try out all the things you can find. Get creative! Any problems you find please file a bug, or report to the IRC channel.

If you have problems with any of the tests, report a bug to Bugzilla usually for the component java-openjdk or java-11-openjdk or java-1.8.0-openjdk. If you are unsure about exactly how to file the report or what other information to include, just ask on IRC and we will help you.

↑I found the different separators between the package names and java versions slightly confusing, and for a second thought it was downgrading. This was totally my carelessness, but I thought I'd admit to it.
$ java --version
openjdk 11-ea 2018-09-25
OpenJDK Runtime Environment (build 11-ea+22)
OpenJDK 64-Bit Server VM (build 11-ea+22, mixed mode, sharing)
RPM install:
Installing:
java-11-openjdk x86_64 1:11.0.ea.28-2.fc29 updates-testing 193 k
All I saw was the "+22" and "-2" until I looked carefully.

↑Sorry, I just read the test case again, and this was expected behaviour. As a user, I would find it very confusing - if I dnf install java , then I would expect the java-devel package to be the same version.

↑Decreasing the VCPU count from 4 to 1 allows me to see the better performance of ShenandoahGC over default GC

↑Shenandoah GC appears to be functionally working as expected. GC does seem smoother/quicker. However I don't really see a pause time impact, really need to do a performance comparison benchmark and on bare metal vs on a VM F29 install. Will require some time to setup a real test, unless we have a specific test case comparison. Do we have a specific comparison?