JDK-8278983 : WebKit 613.1 build fails with Visual Studio 2017
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: openjfx19
  • Priority: P2
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2021-12-18
  • Updated: 2022-02-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
The latest version of WebKit, v613.1, no longer builds with VS 2017.

The first failure that it hits is somewhat similar to the one fixed in WebKit v612.1. This time there are inline constexpr functions that the VS 2017 compiler doesn't like (previously it was inline constexpr variables).


The latest version of WebKit, v613.1, no longer builds with VS 2017.

The first failure that it hits is somewhat similar to the one fixed in WebKit v612.1. This time there are inline constexpr functions that the VS 2017 compiler doesn't like (previously it was inline constexpr variables).


Comments
After doing a quick first pass, there are still remaining compilation failures. This is likely to be enough of a challenge, that we should strongly consider updating JavaFX 11 to Visual Studio 2019. I filed JDK-8281089 to track the jmod issue mentioned in the previous comment that will prevent a jlinked JDK 11.x + JavaFX 11.x from working once we update the compiler.
02-02-2022

The following comment, taken from the Description of JDK-8270479, is relevant to this new failure as well. There are two possible solutions for jfx11u: 1. Find a solution to the VS 2017 compilation issue. We would then fix it in mainline (and 8u) and backport it to 11 along with the backport of WebKit 613.1. 2. Update jfx11u to use VS 2019. This will require solving a long-standing problem where we don't ship the microsoft DLLs in our jmod bundles to avoid the jlink error described in JDK-8207015. Basically our solution to that was to rely on the DLLs in the JDK, which only works if the JDK has the same or newer version of Visual Studio. This means if we update to VS 2019 a jlinked application using JDK 11.0.x and JavaFX 11.0.x will no longer run unless we ship the DLLs (in a separate directory to avoid reintroducing JDK-8207015). Solution 1 might be the easiest, so is probably what we should do for April. We eventually need solution 2 anyway, since it will become increasingly difficult, to build newer WebKit libraries with VS 2017.
18-12-2021

The following comment, taken from the Description of JDK-8270479, is relevant to this new failure as well. There are two possible solutions for jfx11u: 1. Find a solution to the VS 2017 compilation issue. We would then fix it in mainline (and 8u) and backport it to 11 along with the backport of WebKit 613.1. 2. Update jfx11u to use VS 2019. This will require solving a long-standing problem where we don't ship the microsoft DLLs in our jmod bundles to avoid the jlink error described in JDK-8207015. Basically our solution to that was to rely on the DLLs in the JDK, which only works if the JDK has the same or newer version of Visual Studio. This means if we update to VS 2019 a jlinked application using JDK 11.0.x and JavaFX 11.0.x will no longer run unless we ship the DLLs (in a separate directory to avoid reintroducing JDK-8207015). Solution 1 might be the easiest, so is probably what we should do for April. We eventually need solution 2 anyway, since it will become increasingly difficult, to build newer WebKit libraries with VS 2017.
18-12-2021