[rfc] more benevolent java version check

[Martijn Verburg]

Seems to be green now, I'm assuming Mani fixed something.

Cheers,
Martijn

On 2 August 2016 at 22:16, Martijn Verburg <martijnverburg at gmail.com> wrote:

> Hi all,
>
> Apologies, we're struggling a bit to keep all of the builds up on the
> hosted jenkins instance without direct access to the CL.  Hope to have this
> resolved soon.
>
> Cheers,
> Martijn
>
> On 30 July 2016 at 13:44, Jiri Vanek <jvanek at redhat.com> wrote:
>
>> Ouch.
>> It looks like jenkins build is stuck since 25th jul.
>>
>> https://adopt-openjdk.ci.cloudbees.com/job/jtreg/scmPollLog/
>>
>> Started on Jul 29, 2016 9:12:00 PM
>> ERROR: Failed to record SCM polling for hudson.model.FreeStyleProject@
>> 710a47ff[jtreg]
>> java.lang.UnsupportedOperationException
>>         at com.cloudbees.hudson.model.PsuedoNode.createLauncher(
>> PsuedoNode.java:77)
>>         at hudson.tools.JDKInstaller.performInstallation(
>> JDKInstaller.java:143)
>>         at hudson.tools.InstallerTranslator.getToolHome(
>> InstallerTranslator.java:68)
>>         at hudson.tools.ToolLocationNodeProperty.getToolHome(
>> ToolLocationNodeProperty.java:108)
>>         at hudson.tools.ToolInstallation.translateFor(ToolInstallation.
>> java:206)
>>         at hudson.model.JDK.forNode(JDK.java:143)
>>         at hudson.model.AbstractProject.getEnvironment(
>> AbstractProject.java:357)
>>         at hudson.model.AbstractProject.pollWithWorkspace(
>> AbstractProject.java:1460)
>>         at hudson.model.AbstractProject._poll(AbstractProject.java:1438)
>>         at hudson.model.AbstractProject.poll(AbstractProject.java:1349)
>>         at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.
>> java:526)
>>         at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:555)
>>         at hudson.util.SequentialExecutionQueue$QueueEntry.run(
>> SequentialExecutionQueue.java:119)
>>         at java.util.concurrent.Executors$RunnableAdapter.
>> call(Executors.java:511)
>>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>         at java.util.concurrent.ThreadPoolExecutor.runWorker(
>> ThreadPoolExecutor.java:1142)
>>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(
>> ThreadPoolExecutor.java:617)
>>         at java.lang.Thread.run(Thread.java:745)
>>
>> J:(
>>
>> On 07/30/2016 02:35 PM, Jiri Vanek wrote:
>>
>>> On 07/30/2016 03:38 AM, Jonathan Gibbons wrote:
>>>
>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901750
>>>>
>>>> now fixed.
>>>>
>>>
>>>
>>> That was quick :)
>>>  TYVM!
>>>   J.
>>>
>>>
>>>> On 07/27/2016 11:28 AM, Jiri Vanek wrote:
>>>>
>>>>> Hello!
>>>>>
>>>>> Please accept attached patch which is making java version check for
>>>>> other vm more bullet proof.
>>>>>
>>>>> Originally, the java version was strictly expecting the searched item
>>>>> on first line.
>>>>> However, when eg $JAVA_TOOL_OPTIONS is used, the output of forked
>>>>> process got messy. EG:
>>>>>
>>>>> java -version
>>>>> Picked up JAVA_TOOL_OPTIONS: -XX:+UseShenandoahGC
>>>>> OpenJDK 64-Bit Server VM warning: Compressed Oops not supported with
>>>>> ShenandoahGC
>>>>> ....
>>>>>
>>>>> My patch is making the usage of JAVA_TOOL_OPTIONS possible, as it is
>>>>> searching the output of
>>>>> forked process by key.
>>>>>
>>>>>
>>>>> Tahnx!
>>>>>
>>>>>  J.
>>>>>
>>>>
>>>>
>>>
>>
>