Anyone testing on macOS 10.15 betas?
My JavaFX app using JavaFX 13 on OpenJDK 12.0.2 crashes every time I close my main window. I’m not 100% sure if it is a JavaFX issue, but just in case here’s a stack trace. I see libglass.dylib, though it is a few frames away from the crash point.: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x7fff6a488726 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x7fff6a549082 _pthread_cond_wait + 701 2 libjvm.dylib0x00010ffe32d2 os::PlatformEvent::park() + 126 3 libjvm.dylib0x00010ffb95c2 Monitor::ILock(Thread*) + 152 4 libjvm.dylib0x00010ffb9a59 Monitor::lock_without_safepoint_check() + 33 5 libjvm.dylib0x000110049e5a SafepointSynchronize::block(JavaThread*) + 324 6 libjvm.dylib0x0001100e45f0 JavaThread::check_safepoint_and_suspend_for_native_trans(JavaThread*) + 162 7 libjvm.dylib0x00010fdd9d12 jni_NewStringUTF + 142 8 libglass.dylib 0x0001370c6cf9 +[GlassHelper ClassForName:withEnv:] + 185 9 libglass.dylib 0x0001370b3d71 -[GlassTouches(hidden) sendJavaTouchEvent:] + 1441 10 libglass.dylib 0x0001370b3721 listenTouchEvents + 97 11 com.apple.SkyLight 0x7fff6111fdc0 processEventTapData(void*, unsigned int, unsigned int, unsigned int, unsigned char*, unsigned int) + 631 12 com.apple.SkyLight 0x7fff61282680 _XPostEventTapData + 277 13 com.apple.SkyLight 0x7fff6111faeb eventTapMessageHandler(__CFMachPort*, void*, long, void*) + 147 14 com.apple.CoreFoundation0x7fff32d9cfd3 __CFMachPortPerform + 250 15 com.apple.CoreFoundation0x7fff32d9cecf __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41 16 com.apple.CoreFoundation0x7fff32d9ce1f __CFRunLoopDoSource1 + 541 17 com.apple.CoreFoundation0x7fff32d84d7c __CFRunLoopRun + 2612 18 com.apple.CoreFoundation0x7fff32d840c3 CFRunLoopRunSpecific + 499 19 com.apple.HIToolbox 0x7fff31911f2d RunCurrentEventLoopInMode + 292 20 com.apple.HIToolbox 0x7fff31911c6d ReceiveNextEventCommon + 600 21 com.apple.HIToolbox 0x7fff319119f7 _BlockUntilNextEventMatchingListInModeWithFilter + 64 22 com.apple.AppKit0x7fff2ffbbee4 _DPSNextEvent + 990 23 com.apple.AppKit0x7fff2ffbac50 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352 24 com.apple.AppKit0x7fff2ffb5395 -[NSApplication run] + 658 25 libglass.dylib 0x0001370a7e0c -[GlassApplication runLoop:] + 1932 26 com.apple.Foundation0x7fff3553f89a __NSThreadPerformPerform + 254 27 com.apple.CoreFoundation0x7fff32da1cd1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 28 com.apple.CoreFoundation0x7fff32da1c70 __CFRunLoopDoSource0 + 103 29 com.apple.CoreFoundation0x7fff32d85234 __CFRunLoopDoSources0 + 209 30 com.apple.CoreFoundation0x7fff32d84840 __CFRunLoopRun + 1272 31 com.apple.CoreFoundation0x7fff32d840c3 CFRunLoopRunSpecific + 499 32 libjli.dylib0x00010e833444 CreateExecutionEnvironment + 400 33 libjli.dylib0x00010e82f5b7 JLI_Launch + 1311 34 java0x00010e824ca1 main + 375 35 libdyld.dylib 0x7fff6a33c2a5 start + 1 Regards, Scott
Re: Release of OpenJFX 13
Hi Joeri, Am Donnerstag, den 12.09.2019, 09:26 +0200 schrieb Joeri Sykora: > in short, version 13 and 13-ea+14b are binary identical. 13-ea+14 was a > misconfigured maven publication, that caused the platform dependent > artifacts to be missing and should not be used. > > [...] those three versions are maven publications of the exact > same build (built from tag 13+14). [...] thank you, that cleared it and makes sense. Greetings Matthias
Re: Proposal: Migrate official jfx repo to GitHub + Skara tooling
Hearing no objection, we plan to switch the official jfx repo from the existing HG openjfx/jfx-dev/rt [1] repo to the GIT openjdk/jfx [2] repo hosted on GitHub on Thursday, September 26, two weeks from today. By way of disclaimer, please be aware that the JEP for moving the JDK repos to GIT [3] is not yet completed, nor has the follow-on JEP to specify the hosting provider for the JDK repos been filed. As such, this should be considered "early access", although I don't anticipate further changes. Here is an overview of the transition timeline. More details, including actions that OpenJFX Contributors need to take, will be communicated after next week's Oracle Code One. Now through Tuesday, September 24 * Follow the existing procedures for code reviews: either use a PR against the javafxports/openjdk-jfx [4] sandbox repo on GitHub or a webrev posted at cr.openjdk.java.net [5] -- in either case send an RFR email * Approved fixes will continue to be pushed to the HG openjfx/jfx-dev/rt repo by a Committer Wednesday, September 25 * The HG openjfx/jfx-dev/rt repo will be made read-only (exact time tbd, probably around noon Pacific time) * The javafxports/openjdk-jfx sandbox repo will be "retired" at this time. Developers will be responsible for migrating open pull requests to openjdk/jfx (I will send out instructions to make this as easy as possible). Thursday, September 26 * The Skara team will turn off the mirroring of HG openjfx/jfx-dev/rt --> GIT openjdk/jfx * I will push a commit to enable jcheck to the openjdk/jfx repo on GitHub * The Skara team will enable the Skara tooling * I will send an announcement that openjdk/jfx is open for pull requests on GitHub Please let me know if there are any questions about the transition. -- Kevin [1] https://hg.openjdk.java.net/openjfx/jfx-dev/rt [2] https://github.com/openjdk/jfx [3] https://openjdk.java.net/jeps/357 [4] https://github.com/javafxports/openjdk-jfx [5] https://cr.openjdk.java.net/ On 8/20/2019 3:14 PM, Kevin Rushforth wrote: To: OpenJFX Contributors, As most of you are aware, Project Skara is moving forward with a proposed JEP [1] to migrate various OpenJDK projects to git, likely hosted on GitHub. A read-only git mirror of the HG openjfx/jfx-dev/rt repo [2] is available on GitHub at openjdk/jfx [3]. Similarly, there is a read-only mirror of the jdk/jdk repo [4] as well. We've been talking with the Skara team about having OpenJFX be one of the "early adopters" in the git transition. Since a large percentage of the JavaFX code reviews are already happening on GitHub as pull requests against the javafxports/openjdk-jfx (sandbox) mirror, the OpenJFX project would be a natural fit for this. For contributors who are not Committers, there won't be many differences, other than some of the steps will go away (e.g., the Skara tooling will automate the RFR email). For Committers, there will be some minor differences, primarily around eliminating steps -- no more need to merge the pull request into "develop", export the patch, import it into a Mercurial repo, and push it to the official HG repo. Instead, you will use the "/integrate" command as a PR comment to merge the pull request, and then you are done. You will still need to update JBS, at least initially, to resolve the bug as fixed and add the URL to the commit, but even that will be automated at some point. Developers who are interested in leaning more about the Skara tools and workflow can find information on the Skara Wiki [5], GitHub project [6], and mailing list [7]. I note that using the Skara client-side tools on your desktop is completely optional. I expect many (most?) developers will use the GitHub workflow they are already used to via the web interface, but there is an option for those who want to use the command line tools like "git pr". As a final note, I recommend waiting to create a personal fork of the openjdk/jfx mirror, since the Skara team is going to re-convert all openjdk/* mirrors in a couple days [8], and you will just end up having to delete and refork. Comments on this proposal are welcome. -- Kevin [1] https://openjdk.java.net/jeps/357 [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt [3] https://github.com/openjdk/jfx [4] https://github.com/openjdk/jdk [5] https://wiki.openjdk.java.net/display/skara [6] https://github.com/openjdk/skara [7] https://mail.openjdk.java.net/mailman/listinfo/skara-dev [8] https://mail.openjdk.java.net/pipermail/skara-dev/2019-August/000327.html
mmap crash all jvm
Hi, when webview open php_manual_en.html with: virtual box 6.0.10 libc6 2.24-11+deb9u4 openjdk 12.0.1+12 2019-04-16 openjdk 12.0.2 openjdk 14 beter but crash on reload. javafx-sdk-12.0.1 javafx-sdk-12.0.2 kernel 4.19 kernel 5 with vm.max_map_count=200072 libjfxwebkit.so bmalloc crash all my jvm no problem on win 10 Best Regards, Jean-François Martel
Re: Release of OpenJFX 13
Hi Matthias, in short, version 13 and 13-ea+14b are binary identical. 13-ea+14 was a misconfigured maven publication, that caused the platform dependent artifacts to be missing and should not be used. Longer response: those three versions are maven publications of the exact same build (built from tag 13+14). The dates reflect the time when the artifacts were uploaded to the maven central staging repository and not the time of actual release to maven central release repository. I actually didn't know it would keep the dates of the first publication. We'll keep that in mind for the future releases to republish the final version so there is less confusion. I hope this clarifies things for you. Greetings, Joeri
