RFR: JDK-8317308 JavaFX Developer build broken on Windows - NativeLibrary file contains invalid character ':'

[Florian Kirmaier]

On Fri, 29 Sep 2023 10:40:52 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> The format of the timestamp has changed to ISO 8601. This contains the “:” Character.
> A copy of the dll is saved at <home>/.openjfx/cache/" + jfxVersion + "/" + arch .
> On Windows, the character ‘:’ is invalid in files, causing internal errors.
> 
> This only happens on developer/non-hudson builds, because on hudson-builds, the timestamp is omitted.
> 
> I just replaced the disallowed character when creating the native library.

I have to admit that something went wrong here on my side.
On my fork, the code to add the "-internal" for non-hudson builds is removed. Because my builds aren't internal, and I'm also not using hudson.

´´´
    // The version OPT field matches the regular expression "([-a-zA-Z0-9.]+)".
    // For the ISO 8601 basic format, use the pattern "yyyyMMdd'T'HHmmssX".
    def zonedTime = ZonedDateTime.ofInstant(buildInstant, ZoneOffset.UTC)
    def formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd-HHmmss")
    String versionTimestamp = zonedTime.format(formatter)
    relSuffix = "-internal"
    relOpt = "-${versionTimestamp}"
´´´

After I ran into Windows issues, I assumed this was a regression that affected everyone.

Can not create cache at C:\Users\Besi.openjfx\cache\21.0.2.2-jpro+0-2023-09-20T18:43:31Z\amd64
Loading library api-ms-win-core-errorhandling-l1-1-0 from resource failed: java.io.IOException: Can not create cache at C:\Users\Besi\AppData\Local\Temp.openjfx_Besi\cache\21.0.2.2-jpro+0-2023-09-20T18:43:31Z\amd64
java.io.IOException: Can not create cache at C:\Users\Besi\AppData\Local\Temp.openjfx_Besi\cache\21.0.2.2-jpro+0-2023-09-20T18:43:31Z\amd64
        at com.sun.glass.utils.NativeLibLoader.cacheLibrary(NativeLibLoader.java:271)
        at com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:216)
        at com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:198)
        at com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:140)
        at com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:56)
        at com.sun.javafx.tk.Toolkit.loadMSWindowsLibraries(Toolkit.java:172)
        at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:213)
        at com.sun.javafx.perf.PerformanceTracker.logEvent(PerformanceTracker.java:100)
        at javafx.scene.Node.<clinit>(Node.java:417)
        at java.base/java.lang.Class.forName0(Native Method)
        at java.base/java.lang.Class.forName(Class.java:375)
        at com.jpro.internal.server.JProStarter$.startFromBoot(JProStarter.scala:27)
        at com.jpro.internal.server.JProStarter$.main(JProStarter.scala:19)
        at com.jpro.internal.server.JProStarter.main(JProStarter.scala)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at com.jpro.boot.JProBoot.callMain(JProBoot.java:88)
        at com.jpro.boot.JProBoot.lambda$startInThread$0(JProBoot.java:99)
        at java.base/java.lang.Thread.run(Thread.java:833)


Nevertheless, setting a custom version number shouldn't end in a runtime error.
Maybe it's also misleading to call this "Hudson-build" instead of release build.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1251#issuecomment-1742055066