On Fri, 29 Sep 2023 10:40:52 GMT, Florian Kirmaier <fkirma...@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
