Openj9: Test quick start instructions do not work for Java 8

[pshipton]

Looking at the Java 8 build page, https://www.eclipse.org/openj9/oj9_build.html, it refers to the test quick start guide https://github.com/eclipse/openj9/blob/master/test/README.md

• These instructions do not default to Java 8, and do not specify the JAVA_VERSION. Attempting to follow the instructions after finding them from the Java 8 build page does not work, the "make compile" step fails.
• as Java 9 is out of support, the tests should default to something else. https://github.com/eclipse/openj9/blob/master/test/docs/OpenJ9TestUserGuide.md shows the default as SE90.
• after setting JAVA_VERSION=SE80, I reran the configure step and make compile and got an error because I had set JAVA_BIN to the j2sdk-image/bin directory and the compile was looking for j2sdk-image/bin/../../bin/javac, which doesn't work.

[smlambert]

FYI - @renfeiw @llxia

@pshipton - in your opinion, should we have a default and default to SE80, or not default to any version but expect it to be set explicitly.

[DanHeidinga]

I'm not Peter but I have opinions :)

I would prefer it automatically figures out the JAVA_VERSION based on the java under test or always requires it to be set explicitly. An explicit error is much easier to understand and correct.

[smlambert]

So the versions needing support currently are:
Java8 / SE80
Java9 / SE90
Java10 / SE100
Java11 / SE110
Panama
Valhalla (and its variants)
Amber

Is there an easy way to determine those versions from java -version or some other (somewhat foolproof method), similar to VersionCheck code you added?

[DanHeidinga]

Java 8/9/10/11 should be straight forward to figure out from the Java system properties:

$ java -XshowSettings:properties
....
java.vm.specification.version = 1.8

or for 9:

java.vm.specification.version = 9

We'll need to look at the Panama / Valhalla / Amber builds to see if there's a similar property to distinguish them

[smlambert]

Related to #442, to auto-detect settings/variables for testkitgen...

One caveat is that while this sounds desirable (easier / less steps), it can lead to a complaint I hear most often from dev teams. The common complaint is about 'features' in tooling where tools are no longer transparent, but contain lots of hidden logic and perform actions to determine settings on the users behalf (and also hide or store output in files that someone has to dig for). (I recognize the customer set is broad, and we often get conflicting requests, "make it dead easy" and "give me full control and power", difficult to please everyone).

We should be mindful of this (and why we have chosen the explicit setting of variables thus far), so that users stay connected (and therefore empowered) with how their tools work. We can perhaps provide this 'feature', but should not take away the ability to override the auto-detection conveniences if we add them.

[DanHeidinga]

should not take away the ability to override the auto-detection conveniences if we add them.

+1

[pshipton]

Note we could just require the JAVA_VERSION to always be explicitly set (not have a default), and not do any auto-detection.

[pshipton]

There could instead be a sanity check added, at least for SE80 - SE110, i.e. "JAVA_VERSION does not match version of JAVA_BIN"

[pshipton]

Some or all of this has been fixed, I don't expect this needs to remain open.