Integrated: 8326618 : Replace usage of deprecated method getId() in Thread
On Tue, 27 Feb 2024 17:58:13 GMT, Anirvan Sarkar wrote: > Replace Thread.currentThread().getId() with Thread.currentThread().threadId() This pull request has now been integrated. Changeset: 5512a5ad Author: Anirvan Sarkar Committer: John Hendrikx URL: https://git.openjdk.org/jfx/commit/5512a5add0b5ce4a41e6c377c274b9518ee68489 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8326618: Replace usage of deprecated method getId() in Thread Reviewed-by: jhendrikx, kcr - PR: https://git.openjdk.org/jfx/pull/1383
RFR: 8326618 : Replace usage of deprecated method getId() in Thread
Replace Thread.currentThread().getId() with Thread.currentThread().threadId() - Commit messages: - Replace Thread.currentThread().getId() with Thread.currentThread().threadId() Changes: https://git.openjdk.org/jfx/pull/1383/files Webrev: https://webrevs.openjdk.org/?repo=jfx=1383=00 Issue: https://bugs.openjdk.org/browse/JDK-8326618 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1383.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1383/head:pull/1383 PR: https://git.openjdk.org/jfx/pull/1383
Re: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v3]
On Sat, 17 Feb 2024 18:11:09 GMT, Michael Strauß wrote: >> Platform preferences detection doesn't pick up effective macOS system >> preferences if AWT owns the NSApplication and has set its NSAppearance to a >> fixed value. >> >> The workaround is to set the system property >> "apple.awt.application.appearance=system". >> >> If this property is not set, the following warning will be emitted if a >> JavaFX application attempts to use the platform preferences API: >> >> >> WARNING: Reported preferences may not reflect the macOS system preferences >> unless the sytem >> property apple.awt.application.appearance=system is set. This warning can be >> disabled by >> setting javafx.preferences.suppressAppleAwtWarning=true. > > Michael Strauß has updated the pull request incrementally with one additional > commit since the last revision: > > address review comments > Platform preferences detection doesn't pick up effective macOS system > preferences if AWT owns the NSApplication and has set its NSAppearance to a > fixed value. What about SWT ? It looks like SWT also supports dark mode since version 4.12 [1][2]. [1] : https://eclipse.dev/eclipse/news/4.12/platform_isv.php#dark-theme-mac [2] : https://bugs.eclipse.org/bugs/show_bug.cgi?id=540357 - PR Comment: https://git.openjdk.org/jfx/pull/1367#issuecomment-1952905143
JavaFX snapshots in Maven
Hi, I am trying to run tests with the officially released WebKit and Media shared libraries using the -PSTUB_RUNTIME_OPENJFX option [1]. But it is failing in Gradle dependency verification with below error as checksums are missing from verification metadata. A problem occurred evaluating root project 'jfx'. > Dependency verification failed for configuration ':openjfxStubs' 5 artifacts failed verification: - javafx-20-ea+7.pom (org.openjfx:javafx:20-ea+7) from repository MavenRepo - javafx-media-20-ea+7-win.jar (org.openjfx:javafx-media:20-ea+7) from repository MavenRepo - javafx-media-20-ea+7.pom (org.openjfx:javafx-media:20-ea+7) from repository MavenRepo - javafx-web-20-ea+7-win.jar (org.openjfx:javafx-web:20-ea+7) from repository MavenRepo - javafx-web-20-ea+7.pom (org.openjfx:javafx-web:20-ea+7) from repository MavenRepo If the artifacts are trustworthy, you will need to update the gradle/verification-metadata.xml file by following the instructions at https://docs.gradle.org/7.3/userguide/dependency_verification.html#sec:troubleshooting-verification One way of resolving this issue would be to use SNAPSHOT dependencies. Gradle does not verify them as their checksums would always change [2]. Also developers will no longer need to manually check and specify the latest version for the -PSTUB_RUNTIME_OPENJFX option (after changes are made in the build file to always refer to the SNAPSHOT version when this option is specified). But currently in Maven only EA builds of JavaFX are provided. SNAPSHOT builds are not provided. There had been a discussion in the past to not provide SNAPSHOT builds due to some Gradle issue [3]. But since it has been more than 4 years since then, maybe the situation has changed. Is providing SNAPSHOT builds a possibility now ? This will be convenient for developers especially for those who are not actively working on the sources of WebKit and Media libraries. [1] : https://github.com/openjdk/jfx/blob/master/WEBKIT-MEDIA-STUBS.md#officially-released-libraries [2] : https://docs.gradle.org/7.3/userguide/dependency_verification.html#sub:verification-metadata [3] : https://mail.openjdk.org/pipermail/openjfx-dev/2018-July/022107.html -- Anirvan
Re: Switching to ANGLE ?
There is an ANGLE RFE [1]. It is closed as a duplicate of an older WebGL RFE [2]. [1] : https://bugs.openjdk.org/browse/JDK-8134841 [2] : https://bugs.openjdk.org/browse/JDK-8091035 On Wed, 2 Nov 2022 at 7:56 PM, Mike Hearn wrote: > On a topic unrelated to Conveyor, I saw the JavaFX roadmap document > presented at JavaOne and the mention of a Metal pipeline. > > It prompted a thought I've never got around to exploring - does it make > sense to switch JavaFX to using Google's ANGLE library i.e. to decommission > all but the GL backend and then use it on every OS? This would have three > big and obvious advantages: > > 1. A big reduction in the maintenance burden. A metal port is maybe no > longer required. > > 2. A component or canvas that exposes a GL context (implicitly, on the > current thread) could then be provided relatively easily, allowing easier > integration of arbitrary drawing with the scene graph without compromising > portability. > > 3. In turn that would unblock enabling WebGL in the WebView control, > fixing Google Maps. > > It's mostly a question of curiosity but I'm wondering if that approach has > ever been prototyped or explored. > > thanks, > -mike > -- Anirvan
