JDK-8317370 : JavaFX runtime version is wrong at runtime
  • Type: Bug
  • Component: javafx
  • Sub-Component: base
  • Affected Version: jfx21,jfx22
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-10-02
  • Updated: 2023-11-27
  • Resolved: 2023-10-14
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
jfx21.0.2Fixed
Related Reports
Relates :  
JDK-8317308 - JavaFX Developer build broken on Windows - NativeLibrary file contains invalid character ':'
Relates :  
JDK-8264449 - Enable reproducible builds with SOURCE_DATE_EPOCH
Description
The value of the JavaFX runtime version system property, 'javafx.runtime.version', has the wrong format at runtime. Furthermore, its value at runtime is different than its value in the 'javafx.properties' file that is included in the JavaFX SDK package and in the 'javafx.base' JAR file.

SYSTEM / OS / JAVA RUNTIME INFORMATION

My system runs Ubuntu 22.04.3 LTS with the following build tools:

- cmake version 3.26.4
- gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
- OpenJDK Runtime Environment (build 19.0.2+7-44)
- Apache Ant(TM) version 1.10.13 compiled on January 4 2023

STEPS TO REPRODUCE

Build the attached Maven project and run its test cases as follows:

$ mvn clean package

EXPECTED RESULTS

All of the test cases should pass:

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
       ...
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0

ACTUAL RESULT

Two of the test cases fail:

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
       ...
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   VersionInfoTest.testRuntimeVersionFormat:191
          Invalid version string: '21-internal+23-2023-09-29T13:32:53Z'
[ERROR]   VersionInfoTest.testRuntimeVersionInFile:206
          expected:<...ternal+23-2023-09-29[T13:32:53Z]>
           but was:<...ternal+23-2023-09-29[-133253]>
[INFO]
[ERROR] Tests run: 9, Failures: 2, Errors: 0, Skipped: 0

The JavaFX runtime version contains the colon character ":", which is not permitted in a JavaFX version string. In addition, the version string is different at runtime than its value in the 'javafx.properties' file.

SOURCE CODE FOR AN EXECUTABLE TEST CASE

The source code is found in the following GitHub repository:

https://github.com/jgneff/version-info-test

I also attached the files 'pom.xml' and 'VersionInfoTest.java' to this bug report.

WORKAROUND

None.
Comments
> I think we already did this through the labels We did. > Do I understand correctly that I can skip the '/approval' command and go directly to the '/integrate' command in the JavaFX 21 pull request now? Correct. There is nothing else remaining, so this is ready to integrate.
27-11-2023
Fix Request I think we already did this through the labels, but I'm following each step in the instructions for "maintainer approval" just in case (https://openjdk.org/projects/jdk-updates/approval.html). This fix is important because, without it, applications running on developer builds of JavaFX 21 fail to start on Windows and print an error message like the following: java.io.IOException: Can not create cache at C:\Users\...\cache\21.0.2.2-jpro+0-2023-09-20T18:43:31Z\amd64 The fix uses the historical format of the timestamp without the ":" character instead of the ISO 8601 extended format, which causes the failure. I think the risk is low primarily because the fix adds four test cases to the unit tests that verify the timestamp format and verify that the build-time and run-time timestamps are identical. The patch did not apply cleanly because of the line that defines the major (feature) version number, which was 22 in the main JavaFX repository but 21 in this JavaFX 21 updates repository. [~kcr] Thank you, Kevin, for your patience in back-porting this fix. Do I understand correctly that I can skip the '/approval' command and go directly to the '/integrate' command in the JavaFX 21 pull request now?
27-11-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jfx21u/pull/32 Date: 2023-11-21 20:19:04 +0000
21-11-2023
Approved to backport to jfx21u Short answer: yes, you will have a chance to test it after the PR is created. Longer answer: The Skara "/backport" command creates a branch in jpg-forks and gives you a dialog with a link that will allow you to create the PR (so that the PR is owned by you). Once you create the PR, Skara will check if it is clean and verify that the JBS bug is approved to be backported. If so, it will then mark it as ready without needing further review. It then waits for you to "/integrate" it as with any other PR.
20-11-2023
Added the 'jfx21u-fix-request' label to request permission to backport this fix to JavaFX 21. One thing that's not completely clear to me: does the Skara '/backport' command create the pull request and integrate it all in one step, or is there a chance to test the pull request again before it's integrated?
20-11-2023
Yes, you would follow the instructions in that message. Use this bug ID and don't create a new one, although the PR title should be: Backport <COMMITHASH> Where <COMMITHASH> is the 40 character commit hash of the jfx mainline commit. Skara will then note that it is a backport and replace the PR title with this bug ID and title. The easiest way is probably to use the "/backport" command, but you can create your own using your own personal fork of jfx21u if you prefer. See: https://wiki.openjdk.org/display/SKARA/Backports
15-11-2023
[~kcr] Sure! I haven't done that before. Do I Just follow the instructions in your message below? jfx21u open for JavaFX 21.0.1 backports https://mail.openjdk.org/pipermail/openjfx-dev/2023-August/042200.html Does that mean I do not open another bug report here for the backport, and instead reuse the number of this bug report for the pull request title? Thanks, John
15-11-2023
[~jgneff] Would you be willing to backport this to jfx21u? This will allow developer builds to be created without the issue reported in JDK-8317308.
14-11-2023
Changeset: 16169240 Author: John Neffenger <jgneff@openjdk.org> Date: 2023-10-14 16:32:26 +0000 URL: https://git.openjdk.org/jfx/commit/16169240667876633895b27464eb90033abb6166
14-10-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jfx/pull/1253 Date: 2023-10-02 22:06:38 +0000
04-10-2023
Raising the priority to P3, since this is a regression that could (and has) cause problems. Once integrated, we should backport this fix to jfx21u (for 21.0.2, although it doesn't affect production builds, so the important thing is to just get the backport in for developer / internal builds).
04-10-2023
I ran the provided test cases against JavaFX build 21+22, build 21+23, and then a build of the #1253 pull request branch that fixes this bug ('javafx-runtime-version'). I used commands like the following to publish the Maven artifacts to my local repository, shown below for JavaFX 21+22. $ git checkout 21+22 $ git clean -fdx $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) $ bash gradlew -PPROMOTED_BUILD_NUMBER=22 sdk jmods javadoc $ bash gradlew -PPROMOTED_BUILD_NUMBER=22 \ -PMAVEN_PUBLISH=true publishToMavenLocal I modified the version string in the 'pom.xml' file before running each set of JUnit test cases: <dependency> <groupId>org.openjfx</groupId> <artifactId>javafx-base</artifactId> <version>22-internal+0-2023-09-29-133253</version> </dependency> The results were: * 21+22 (21-internal+22-2023-10-02-114811) works * 21+23 (21-internal+23-2023-09-29-133253) fails * PR#1253 (22-internal+0-2023-09-29-133253) works
04-10-2023