Sorry That last build with the Oracle OpenJDK needed the build file changed to have
vendor = JvmVendorSpec.ORACLE as well as the command line property pointing to the path to the jdk, Scott > On Sep 22, 2021, at 10:24 AM, Scott Palmer <swpal...@gmail.com> wrote: > > I reproduced it with the AZUL's distribution of OpenJDK (with JavaFX modules > bundled) and I just changed: > > vendor = JvmVendorSpec.ADOPTOPENJDK > > And get the same error with that build of OpenJDK as well. “OpenJDK Runtime > Environment Temurin-17+35 (build 17+35)” > You can try that, as Gradle should download the JDK for you. > > I then downloaded the Oracle build of OpenJDK from https://jdk.java.net/17/ > (build 17+35-2724) > unzipped it to C:\Tools > building with: > > gradlew -Porg.gradle.java.installations.paths=C:\Tools\jdk-17 clean build > > I still reproduce the error. > > Though the assertion in native JVM code that you are getting looks like yet > another bug! So perhaps it is good that it is discovered as well. > > > Scott > >> On Sep 22, 2021, at 9:54 AM, Andy Herrick <andy.herr...@oracle.com> wrote: >> >> I can't seem to get your testcase to work with the Oracle JDK configured. >> >> I can build, but then when I run >> >> $ ./build/application/FetchURL/FetchURL.exe >> >> I get: >> >>> *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with >>> message c >>> an't find transform methodID at JPLISAgent.c line: 552 >>> *** java.lang.instrument ASSERTION FAILED ***: "result" at JPLISAgent.c >>> line: 400 >>> >>> FATAL ERROR in native method: processing of -javaagent failed >> same behavior if I restore "runtime" directory and fix FetchURL.cfg to >> remove app.runtime entry. >> >> anyway I used your two source files to build the test app without gradle, >> and the test can download >> https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8 >> without any problems. >> >> I then moved runtime to jre and added line "app.runtime=$APPDIR/../jre" to >> cfg file and app still ran fine (downloaded the above) >> >> So I still don't have any way to reproduce this problemwith the Oracle jdk. >> >> /Andy >> >> >> PS: >> >> Although something somewhere else may have changed to counter the problem, >> it's clear from your description, that since the only place in the code the >> default runtime path is used (instead of the actual runtime path, which may >> be different) is the line in WinLauncher.cpp to call SetDllDirectory(). >> >> This should be fixed - but would like a way to reproduce the problem it >> causes first. >> >> /Andy >> >> On 9/21/2021 12:12 PM, Andy Herrick wrote: >>> I thought I could create a reproduction scenario by using an app with >>> "-splash:<image file>" arg then moving the jre as you did, but I have not >>> yet been able make it fail. >>> >>> /Andy >>> >>> On 9/21/2021 11:43 AM, Scott Palmer wrote: >>>>> On Sep 21, 2021, at 11:40 AM, Alan Bateman <alan.bate...@oracle.com> >>>>> wrote: >>>>> >>>>> On 21/09/2021 15:54, Andy Herrick wrote: >>>>>> I found the problem in >>>>>> open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp >>>>>> >>>>>> we call SetDllDirectory() with the path to the bin dir in the default >>>>>> runtime directory, not the actual runtime directory. >>>>>> >>>>>> since on Windows we never use other than the default runtime location - >>>>>> we had not seen a problem, but is bug I will file and fix. >>>>>> >>>>> Good to see that you found it quickly. However I'm puzzled as why >>>>> initializingEncoding wasn't called, I would have expected the VM to blow >>>>> up during early startup. Would you have cycles to dig into that a bit >>>>> more in case something has been masked, like for example an exception >>>>> being swallowed. Running with -Xlog:exceptions might reveal something. >>>> >>>> Do you have a case that reproduces the issue? >>>> >>>> Scott >
