Temurin-build: Compile Windows Java 15+ using VS2019

[pshipton]

OpenJDK Java 15+ sets the default compiler for Windows to VS2019. Both Hotspot and OpenJ9 should be compiled with this version. OpenJ9 made the switch already for Java 15 GA, so we know it's working.
https://github.com/eclipse/openj9/issues/9805
https://github.com/eclipse/openj9/pull/10302

[pshipton]

For OpenJ9, I expect this also means creating a VS2019 pre-compiled version of openssl to use for the Java 15+ builds.

[pshipton]

Time is short before the Oct 20 release. I'm not requesting the change be done before this release, but it should be done for the next one.

[jdekonin]

Playbook updates already made, might just be a build side change that is needed??
https://github.com/AdoptOpenJDK/openjdk-infrastructure/pull/1481

[sxa]

(Hope you don't mind me clarifying the title Peter!)

I agree that we shouldn't do it before the GA so we can queue this up for afterwards.

[pshipton]

Hotspot Java 15+ builds should change to use VS2019 as well. According to Joe they don't use it now. The new title seems misleading, unless there is another issue opened to change Hotspot builds.

[sxa]

OK. For completeness can you provide a reference to the change in default in OpenJDK?

[pshipton]

https://github.com/ibmruntimes/openj9-openjdk-jdk15/blob/openj9/make/autoconf/toolchain_windows.m4#L28

# The order of these defines the priority by which we try to find them.
VALID_VS_VERSIONS="2019 2017 2013 2015 2012 2010"

http://hg.openjdk.java.net/jdk-updates/jdk15u/file/dee440862fbe/make/autoconf/toolchain_windows.m4

[pshipton]

Compare to Java 11
https://github.com/ibmruntimes/openj9-openjdk-jdk11/blob/openj9/make/autoconf/toolchain_windows.m4#L28

# The order of these defines the priority by which we try to find them.
VALID_VS_VERSIONS="2017 2013 2015 2012 2010"

[sxa]

I think we're safely beyond the releases now (fingers crossed, macos excepted!) so we can look into this again
@d3r3kk @karianna Any views on this?

Related: #1026

[pshipton]

Is this going to happen for the 15.0.2 release?

[aahlenst]

@pshipton If I'm not mistaken, January will be the last release of 15. So maybe we just skip it if there aren't any problems caused by VS 2017. My appetite for experiments is low. But what would be great is to change to VS 2019 for 16 and 17. Can you make a PR?

(But you can convince me otherwise!)

[pshipton]

It shouldn't be much of an experiment since OpenJ9 has been compiling 15+ with VS2019 since before the last release. Although I suppose there could be a change in measured performance, which we don't want at the last minute.

Can you make a PR?

I don't have any experience making this type of change at Adopt, I'll leave it for Stewart or someone else. If it doesn't happen until Java 16, that's fine, as long as it's not forgotten.

[sxa]

I'm personally ok with making this change on the basis that it's been well tested at OpenJ9 (although VS2019 has NOT been well tested at adopt yet obviously!) - if we can get it in we can leave it running over the next week or so and if we conclude it's a bad idea for whatever reason we can back it out before the GA for 15.

PR raised as per the message above this comment :-)

[aahlenst]

@sxa Reopening because your PR was only for OpenJ9, not Hotspot. Hotspot is still 2017 but should be 2019, too, see https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms.

[sxa]

Yep thanks for reopening - HotSpot is a separate question - I wasn't expecting us to move that immediately - that'll need some wider discussion (likely with input from the MSFT team although I'm not sure how involved @d3r3kk is now).

[aahlenst]

I'm not sure that sticking to the default toolchain used by OpenJDK warrants a lot of discussion and deliberation. The problem is usually deviating from the default toolchain which we're doing right now without having had that discussion.

[sxa]

Only outstanding issue should be addressed with #2438 - with 15 out of service there is no reason to adjust the process for that version. Closing