Closed Mesbah-Alam closed 3 years ago
Tested : internal/Grinder/14822
Note: the original issue which causes java -version
to output JVMJ9VM090I was not reproducible.
@peter_shipton@ca.ibm.com - please review.
Does it make sense to use String.matches()
with regex (openjdk|java) version
? We just need to validate that java -version output contains (openjdk|java) version
. Does it matter if it contains any other messages?
We just need to validate that java -version output contains (openjdk|java) version
The way this piece of STF code was implemented is suggestive of the fact that the people involved in coding it had decided to validate if java -version output starts with 'java version'. I have no knowledge of why they decided to do that.
If we want to change this check's criteria, we can change it to whatever we want. We just need to come to an agreement. That's all.
FYI @lumpfish
@llxia : As discussed at the AQAvit call, could we deliver this PR so that it unblocks build from any reoccurrence of the issue reported in https://github.com/eclipse/openj9/issues/12470?
As the next step, I'll create a second issue to remove the version check altogether and update the logic of figuring out various Java versions in JavaVersion.java to depend on Java system properties instead of parsing java -version
output.
Issue for second step mentioned above: https://github.com/adoptium/STF/issues/114
We are still technically in a code freeze for release week.
We are still technically in a code freeze for release week.
That was a slip from my side!
This PR is to Ignore JVMJ9VM090I messages in java -version output.
it should fix the related issue reported in to https://github.com/eclipse/openj9/issues/12470. Meaning, next time we encounter network issues which cause
java -version
to outputJVMJ9VM090I
as below, STF would ignore it and continue.Signed-off-by: Mesbah_Alam@ca.ibm.com Mesbah_Alam@ca.ibm.com