From nlisker at gmail.com Mon Jul 1 04:41:39 2019 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 1 Jul 2019 07:41:39 +0300 Subject: Review Request: JDK-8226912: Color, Point2D and Point3D's fields should be made final Message-ID: Hi Kevin, Please review the simple fix for: https://bugs.openjdk.java.net/browse/JDK-8226912 http://cr.openjdk.java.net/~nlisker/8226912/webrev.00/ I planned this for 14, but it can go into 13 too. - Nir From rajath.kamath at oracle.com Mon Jul 1 04:56:04 2019 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Sun, 30 Jun 2019 21:56:04 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Nir Lisker In-Reply-To: References: Message-ID: <9f676a5f-72bb-461e-827e-b79e75fa257b@default> Vote: YES Best Regards, Rajath -----Original Message----- From: Kevin Rushforth Sent: Wednesday, June 26, 2019 3:14 AM To: openjfx-dev at openjdk.java.net; Nir Lisker Subject: CFV: New OpenJFX Committer: Nir Lisker I hereby nominate Nir Lisker [1] to OpenJFX Committer. Nir is an OpenJFX community member, who has contributed 16 changesets [2][3] to OpenJFX. Votes are due by July 13, 2019. Only current OpenJFX Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. Nomination to a project Committer is described in [6]. Thanks. -- Kevin [1] http://openjdk.java.net/census#nlisker [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28nlisker%29 [3] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=nlisker%40gmail [4] http://openjdk.java.net/census#openjfx [5] http://openjdk.java.net/bylaws#lazy-consensus [6] http://openjdk.java.net/projects#project-committer From ambarish.rapte at oracle.com Tue Jul 2 11:45:18 2019 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Tue, 2 Jul 2019 04:45:18 -0700 (PDT) Subject: [Openjfx13] RFR : JDK-8209938 : Default and Cancel button cause memory leak Message-ID: <1de60839-0365-4111-bf67-850b125dda33@default> Hi All, Please review this fix: JBS: https://bugs.openjdk.java.net/browse/JDK-8209938 Webrev: http://cr.openjdk.java.net/~arapte/fx/8209938/webrev.00/ Regards, Ambarish From arunprasad.rajkumar at oracle.com Wed Jul 3 11:37:03 2019 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 3 Jul 2019 17:07:03 +0530 Subject: [RFR][openjfx13] 8227079: Cherry pick GTK WebKit 2.24.3 changes Message-ID: <0C004C8A-DA80-40B8-8893-E144C357161A@oracle.com> Hi Kevin, Johan, Please review the following PR which merges changes from GTK WebKit 2.24.3 release. https://github.com/javafxports/openjdk-jfx/pull/515 Thanks, Arun From r.lichtenberger at gmail.com Thu Jul 4 15:01:32 2019 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Thu, 4 Jul 2019 17:01:32 +0200 Subject: Windows (32bit) build problems Message-ID: Hello everyone, I try to build JavaFX-12 mods for Windows-32. For that I cloned http://hg.openjdk.java.net/openjfx/12-dev/rt/ (correct?) and read the build instructions at https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Windows . First question: * The build instructions tell me that gradle 5.3 is used but the gradle-wrapper actually downloads 4.8. My guess is that the build instructions refer to the current head version. * A simple ./gradlew tasks gives the following error: > * What went wrong: > A problem occurred evaluating script. > > FAIL: WINSDK_DIR not defined > There's no such environment variable in the build instructions. By looking around in win.gradle I guessed that this should point to the "Microsoft DirectShow header files", but it is not really well documented. I could only make the build continue by patching win.gradle, setting an environment variable did not help. If I add WINDOWS_SDK_DIR="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1" in win.gradle right above the checking code, I can execute gradlew tasks. However If I just start gradlew to really build JavaFX I get: FAILURE: Build failed with an exception. > > * What went wrong: > Execution failed for task ':graphics:compileDecoraNativeShadersWin'. > > java.util.concurrent.ExecutionException: > org.gradle.process.internal.ExecException: A problem occurred starting > process 'command '/VC/BIN/cl.exe'' > Any help/hints welcome :-) From nlisker at gmail.com Thu Jul 4 15:28:35 2019 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 4 Jul 2019 18:28:35 +0300 Subject: Windows (32bit) build problems In-Reply-To: References: Message-ID: Hi Robert, My guess is that the build > instructions refer to the current head version. Correct. Gradle version was changed from 4.8 to 5.3 during the development of OpenJFX 13 [1], so for 12 you will need 4.8. I don't have time right now to look at the WinSDK issue, but you can look at the build instructions page at the time of OpenJFX 12 release [2]. - Nir [1] https://bugs.openjdk.java.net/browse/JDK-8218172 [2] https://wiki.openjdk.java.net/pages/viewpreviousversions.action?pageId=8257548 On Thu, Jul 4, 2019 at 6:02 PM Robert Lichtenberger < r.lichtenberger at gmail.com> wrote: > Hello everyone, > > I try to build JavaFX-12 mods for Windows-32. > > For that I cloned http://hg.openjdk.java.net/openjfx/12-dev/rt/ (correct?) > and read the build instructions at > > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Windows > . > > First question: > * The build instructions tell me that gradle 5.3 is used but the > gradle-wrapper actually downloads 4.8. My guess is that the build > instructions refer to the current head version. > * A simple ./gradlew tasks gives the following error: > > > * What went wrong: > > A problem occurred evaluating script. > > > FAIL: WINSDK_DIR not defined > > > There's no such environment variable in the build instructions. By looking > around in win.gradle I guessed that this should point to the "Microsoft > DirectShow header files", but it is not really well documented. > I could only make the build continue by patching win.gradle, setting an > environment variable did not help. > > If I add WINDOWS_SDK_DIR="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1" > in win.gradle right above the checking code, I can execute gradlew tasks. > > However If I just start gradlew to really build JavaFX I get: > > FAILURE: Build failed with an exception. > > > > * What went wrong: > > Execution failed for task ':graphics:compileDecoraNativeShadersWin'. > > > java.util.concurrent.ExecutionException: > > org.gradle.process.internal.ExecException: A problem occurred starting > > process 'command '/VC/BIN/cl.exe'' > > > > Any help/hints welcome :-) > From swpalmer at gmail.com Thu Jul 4 22:25:36 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 4 Jul 2019 18:25:36 -0400 Subject: Fix for JDK-8185937 Up/Down keys don't work as expected for an editable Spinner Message-ID: <707C1F51-69F9-4962-8101-01DF32EFEE05@gmail.com> I?ve added my potential fix as a comment to the issue at https://bugs.openjdk.java.net/browse/JDK-8185937 Scott From r.lichtenberger at gmail.com Fri Jul 5 06:59:37 2019 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Fri, 5 Jul 2019 08:59:37 +0200 Subject: Windows (32bit) build problems In-Reply-To: References: Message-ID: I've started from scratch and one obvious problem in win.gradle is this line: > > defineProperty("WINDOWS_VS_VSINSTALLDIR", properties, "c:/Program > Files (x86)/Microsoft Visual Studio/2017/Professional"); as it hardcodes the Professional version of VS. I've also found [1] which indicates that this kind of problem isn't uncommon or new :-). It also seems to me that the environment variable WINSDK_DIR has to be set (before launching any gradle task) on windows which should be added to the documentation. So after setting the environment varialbe and patching win.gradle to point to the Community Edition I've installed I now get a new error: > * What went wrong: > A problem occurred evaluating script. > > FAIL: cannot find RC: C:/Program Files/Microsoft > SDKs/Windows/v7.1/Bin/10.0.17134.0/x86/rc.exe I'll try and find out why that happens... [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-October/020861.html Am Do., 4. Juli 2019 um 17:29 Uhr schrieb Nir Lisker : > Hi Robert, > > My guess is that the build >> instructions refer to the current head version. > > > Correct. > > Gradle version was changed from 4.8 to 5.3 during the development of > OpenJFX 13 [1], so for 12 you will need 4.8. > > I don't have time right now to look at the WinSDK issue, but you can look > at the build instructions page at the time of OpenJFX 12 release [2]. > > - Nir > > [1] https://bugs.openjdk.java.net/browse/JDK-8218172 > > [2] > https://wiki.openjdk.java.net/pages/viewpreviousversions.action?pageId=8257548 > > On Thu, Jul 4, 2019 at 6:02 PM Robert Lichtenberger < > r.lichtenberger at gmail.com> wrote: > >> Hello everyone, >> >> I try to build JavaFX-12 mods for Windows-32. >> >> For that I cloned http://hg.openjdk.java.net/openjfx/12-dev/rt/ >> (correct?) >> and read the build instructions at >> >> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Windows >> . >> >> First question: >> * The build instructions tell me that gradle 5.3 is used but the >> gradle-wrapper actually downloads 4.8. My guess is that the build >> instructions refer to the current head version. >> * A simple ./gradlew tasks gives the following error: >> >> > * What went wrong: >> > A problem occurred evaluating script. >> > > FAIL: WINSDK_DIR not defined >> > >> There's no such environment variable in the build instructions. By looking >> around in win.gradle I guessed that this should point to the "Microsoft >> DirectShow header files", but it is not really well documented. >> I could only make the build continue by patching win.gradle, setting an >> environment variable did not help. >> >> If I add WINDOWS_SDK_DIR="C:\\Program Files\\Microsoft >> SDKs\\Windows\\v7.1" >> in win.gradle right above the checking code, I can execute gradlew tasks. >> >> However If I just start gradlew to really build JavaFX I get: >> >> FAILURE: Build failed with an exception. >> > >> > * What went wrong: >> > Execution failed for task ':graphics:compileDecoraNativeShadersWin'. >> > > java.util.concurrent.ExecutionException: >> > org.gradle.process.internal.ExecException: A problem occurred starting >> > process 'command '/VC/BIN/cl.exe'' >> > >> >> Any help/hints welcome :-) >> > From sproket at videotron.ca Fri Jul 5 09:32:30 2019 From: sproket at videotron.ca (Dan Howard) Date: Fri, 5 Jul 2019 05:32:30 -0400 Subject: Windows (32bit) build problems In-Reply-To: References: Message-ID: <9164e13d-b3d9-e073-9910-c092255cb93c@videotron.ca> You will need Windows 7 or later (Windows 10 is recommended) 64-bit OS On 7/4/2019 11:01 AM, Robert Lichtenberger wrote: > Hello everyone, > > I try to build JavaFX-12 mods for Windows-32. > > For that I cloned http://hg.openjdk.java.net/openjfx/12-dev/rt/ (correct?) > and read the build instructions at > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Windows > . > > First question: > * The build instructions tell me that gradle 5.3 is used but the > gradle-wrapper actually downloads 4.8. My guess is that the build > instructions refer to the current head version. > * A simple ./gradlew tasks gives the following error: > >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined > There's no such environment variable in the build instructions. By looking > around in win.gradle I guessed that this should point to the "Microsoft > DirectShow header files", but it is not really well documented. > I could only make the build continue by patching win.gradle, setting an > environment variable did not help. > > If I add WINDOWS_SDK_DIR="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1" > in win.gradle right above the checking code, I can execute gradlew tasks. > > However If I just start gradlew to really build JavaFX I get: > > FAILURE: Build failed with an exception. >> * What went wrong: >> Execution failed for task ':graphics:compileDecoraNativeShadersWin'. >>> java.util.concurrent.ExecutionException: >> org.gradle.process.internal.ExecException: A problem occurred starting >> process 'command '/VC/BIN/cl.exe'' >> > Any help/hints welcome :-) > From mike.ennen at gmail.com Fri Jul 5 18:02:48 2019 From: mike.ennen at gmail.com (Michael Ennen) Date: Fri, 5 Jul 2019 11:02:48 -0700 Subject: Windows (32bit) build problems In-Reply-To: References: Message-ID: I recommend using https://github.com/javafxports/openjdk-jfx/blob/develop/tools/scripts/build.ps1 when trying to build OpenJFX locally on Windows. I personally use it with the "-nocygwin" argument so that it does not try and auto-install cygwin. On Fri, Jul 5, 2019 at 5:31 AM Robert Lichtenberger < r.lichtenberger at gmail.com> wrote: > I've started from scratch and one obvious problem in win.gradle is this > line: > > > > defineProperty("WINDOWS_VS_VSINSTALLDIR", properties, "c:/Program > > Files (x86)/Microsoft Visual Studio/2017/Professional"); > > as it hardcodes the Professional version of VS. > > I've also found [1] which indicates that this kind of problem isn't > uncommon or new :-). > > It also seems to me that the environment variable WINSDK_DIR has to be set > (before launching any gradle task) on windows which should be added to the > documentation. > > So after setting the environment varialbe and patching win.gradle to point > to the Community Edition I've installed I now get a new error: > > > * What went wrong: > > A problem occurred evaluating script. > > > FAIL: cannot find RC: C:/Program Files/Microsoft > > SDKs/Windows/v7.1/Bin/10.0.17134.0/x86/rc.exe > > > I'll try and find out why that happens... > > [1] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-October/020861.html > > Am Do., 4. Juli 2019 um 17:29 Uhr schrieb Nir Lisker : > > > Hi Robert, > > > > My guess is that the build > >> instructions refer to the current head version. > > > > > > Correct. > > > > Gradle version was changed from 4.8 to 5.3 during the development of > > OpenJFX 13 [1], so for 12 you will need 4.8. > > > > I don't have time right now to look at the WinSDK issue, but you can look > > at the build instructions page at the time of OpenJFX 12 release [2]. > > > > - Nir > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8218172 > > > > [2] > > > https://wiki.openjdk.java.net/pages/viewpreviousversions.action?pageId=8257548 > > > > On Thu, Jul 4, 2019 at 6:02 PM Robert Lichtenberger < > > r.lichtenberger at gmail.com> wrote: > > > >> Hello everyone, > >> > >> I try to build JavaFX-12 mods for Windows-32. > >> > >> For that I cloned http://hg.openjdk.java.net/openjfx/12-dev/rt/ > >> (correct?) > >> and read the build instructions at > >> > >> > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Windows > >> . > >> > >> First question: > >> * The build instructions tell me that gradle 5.3 is used but the > >> gradle-wrapper actually downloads 4.8. My guess is that the build > >> instructions refer to the current head version. > >> * A simple ./gradlew tasks gives the following error: > >> > >> > * What went wrong: > >> > A problem occurred evaluating script. > >> > > FAIL: WINSDK_DIR not defined > >> > > >> There's no such environment variable in the build instructions. By > looking > >> around in win.gradle I guessed that this should point to the "Microsoft > >> DirectShow header files", but it is not really well documented. > >> I could only make the build continue by patching win.gradle, setting an > >> environment variable did not help. > >> > >> If I add WINDOWS_SDK_DIR="C:\\Program Files\\Microsoft > >> SDKs\\Windows\\v7.1" > >> in win.gradle right above the checking code, I can execute gradlew > tasks. > >> > >> However If I just start gradlew to really build JavaFX I get: > >> > >> FAILURE: Build failed with an exception. > >> > > >> > * What went wrong: > >> > Execution failed for task ':graphics:compileDecoraNativeShadersWin'. > >> > > java.util.concurrent.ExecutionException: > >> > org.gradle.process.internal.ExecException: A problem occurred starting > >> > process 'command '/VC/BIN/cl.exe'' > >> > > >> > >> Any help/hints welcome :-) > >> > > > -- Michael Ennen From swpalmer at gmail.com Fri Jul 5 18:59:51 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 5 Jul 2019 14:59:51 -0400 Subject: RFR: 8185937 - Spinner with Double/Integer value factory ignores up/down arrow keys Message-ID: <7991F641-C870-4651-AFB9-1FC50BB1C19A@gmail.com> Please review the fix for JDK-8185937 - Spinner with Double/Integer value factory ignores up/down arrow keys https://bugs.openjdk.java.net/browse/JDK-8185937 https://github.com/javafxports/openjdk-jfx/pull/517 From youngty1997 at gmail.com Sat Jul 6 05:35:32 2019 From: youngty1997 at gmail.com (Ty Young) Date: Sat, 6 Jul 2019 00:35:32 -0500 Subject: Previews for shared buffer PR In-Reply-To: <68bf79f7-283c-c465-b424-1da90f72b17a@gmail.com> References: <68bf79f7-283c-c465-b424-1da90f72b17a@gmail.com> Message-ID: <1c013f6f-10b7-7410-c490-16452f3872c7@gmail.com> On 6/7/19 4:40 AM, Johan Vos wrote: > The PR discussed in https://github.com/javafxports/openjdk-jfx/pull/472, > addressing https://bugs.openjdk.java.net/browse/JDK-8167148 provides a > very > much wanted feature. It is important that things are done in the right way > so that the code can be maintained in the long-term future. > Therefore, feedback on this PR is extremely important before we can > consider merging it. Once this PR is merged, there is no easy way back. It > is possible to add more functionality, hence my preference is to only > implement the functionality that is safe and stable, while allowing other > functionality to be added later or by third-party extensions. (e.g. > (avoiding) copying from/to GPU) > > To make it easier to give feedback, we've build early access versions of > SDK's including this PR. Note that the PR is not merged, hence not > available in the regular EA downloads! > > If you want to give it a try, download the SDK's from the URL's below. > There is a test in tests/manual/graphics/PixelBufferPerformanceTest ( > https://github.com/arapte/openjdk-jfx/blob/JDK-8167148-NIO-ByteBuffer/tests/manual/graphics/PixelBufferPerformanceTest.java) > that should get you started. > > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_linux-x64_bin-jmods.zip > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_linux-x64_bin-sdk.zip > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_osx-x64_bin-jmods.zip > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_osx-x64_bin-sdk.zip > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_windows-x64_bin-jmods.zip > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_windows-x64_bin-sdk.zip > > - Johan FYI this SDK causes a hard system crash when GTK is set to 2 and/or prism.forceUploadingPainter is set to true. I don't feel like purposefully crashing my system to see which of the various combinations is the issue so forgive me for not providing a more narrowed down cause. GTK 2 is still necessary as there are still lingering GTK3 bugs that have yet to be fixed even in current JavaFX 13. prism.forceUploadingPainter is a prism setting that fixes buffer resets and other various GUI glitching under Linux(an issue I tried reporting a long time ago) which affects ALL JavaFX applications under Linux but dramatically increases GPU utilization by 2x-2.5x when doing any kind of application interaction(resizing, scrolling, etc). Is there a reason this isn't enabled by default under Linux besides performance? Where is the documentation for this and other settings? I randomly ran into this from http://werner.yellowcouch.org/log/javafx-8-command-line-options/ and was surprised noone really knows about it nor is it documented anywhere that I can see. Even with GTK 3 this results in a null pointer exception: java.lang.NullPointerException ??? at javafx.graphics/com.sun.prism.es2.ES2SwapChain.createGraphics(ES2SwapChain.java:223) ??? at javafx.graphics/com.sun.prism.es2.ES2SwapChain.createGraphics(ES2SwapChain.java:40) ??? at javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:87) ??? at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ??? at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ??? at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) ??? at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ??? at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ??? at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125 Please don't merge this into JDK13 or at least provide a switch to disable it. This is extremely busted on Linux. Can the source code for this entire JavaFX build please be linked? From kevin.rushforth at oracle.com Sat Jul 6 16:42:42 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 6 Jul 2019 09:42:42 -0700 Subject: Previews for shared buffer PR In-Reply-To: <1c013f6f-10b7-7410-c490-16452f3872c7@gmail.com> References: <68bf79f7-283c-c465-b424-1da90f72b17a@gmail.com> <1c013f6f-10b7-7410-c490-16452f3872c7@gmail.com> Message-ID: There might be other issues with the early access. The shared NIO buffer feature should be behavior-neutral if you don't use it. So either there is some other issue with it, or there is a bug. Given the number of changes since that early access, both in the JavaFX 13 code base and in the PR itself, it seems worth making a new early access for people to try. I'll also do some local testing both with GTK 2 and GTK3. -- Kevin On 7/5/2019 10:35 PM, Ty Young wrote: > > > On 6/7/19 4:40 AM, Johan Vos wrote: >> The PR discussed in https://github.com/javafxports/openjdk-jfx/pull/472, >> addressing https://bugs.openjdk.java.net/browse/JDK-8167148 provides >> a very >> much wanted feature. It is important that things are done in the >> right way >> so that the code can be maintained in the long-term future. >> Therefore, feedback on this PR is extremely important before we can >> consider merging it. Once this PR is merged, there is no easy way >> back. It >> is possible to add more functionality, hence my preference is to only >> implement the functionality that is safe and stable, while allowing >> other >> functionality to be added later or by third-party extensions. (e.g. >> (avoiding) copying from/to GPU) >> >> To make it easier to give feedback, we've build early access versions of >> SDK's including this PR. Note that the PR is not merged, hence not >> available in the regular EA downloads! >> >> If you want to give it a try, download the SDK's from the URL's below. >> There is a test in tests/manual/graphics/PixelBufferPerformanceTest ( >> https://github.com/arapte/openjdk-jfx/blob/JDK-8167148-NIO-ByteBuffer/tests/manual/graphics/PixelBufferPerformanceTest.java) >> >> that should get you started. >> >> https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_linux-x64_bin-jmods.zip >> >> https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_linux-x64_bin-sdk.zip >> >> https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_osx-x64_bin-jmods.zip >> >> https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_osx-x64_bin-sdk.zip >> >> https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_windows-x64_bin-jmods.zip >> >> https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_windows-x64_bin-sdk.zip >> >> >> - Johan > > > FYI this SDK causes a hard system crash when GTK is set to 2 and/or > prism.forceUploadingPainter is set to true. I don't feel like > purposefully crashing my system to see which of the various > combinations is the issue so forgive me for not providing a more > narrowed down cause. > > GTK 2 is still necessary as there are still lingering GTK3 bugs that > have yet to be fixed even in current JavaFX 13. > > prism.forceUploadingPainter is a prism setting that fixes buffer > resets and other various GUI glitching under Linux(an issue I tried > reporting a long time ago) which affects ALL JavaFX applications under > Linux but dramatically increases GPU utilization by 2x-2.5x when doing > any kind of application interaction(resizing, scrolling, etc). Is > there a reason this isn't enabled by default under Linux besides > performance? Where is the documentation for this and other settings? I > randomly ran into this from > http://werner.yellowcouch.org/log/javafx-8-command-line-options/ and > was surprised noone really knows about it nor is it documented > anywhere that I can see. > > > Even with GTK 3 this results in a null pointer exception: > > > java.lang.NullPointerException > ??? at > javafx.graphics/com.sun.prism.es2.ES2SwapChain.createGraphics(ES2SwapChain.java:223) > ??? at > javafx.graphics/com.sun.prism.es2.ES2SwapChain.createGraphics(ES2SwapChain.java:40) > ??? at > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:87) > ??? at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > ??? at > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > ??? at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > ??? at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > ??? at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > ??? at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125 > > > Please don't merge this into JDK13 or at least provide a switch to > disable it. This is extremely busted on Linux. > > > Can the source code for this entire JavaFX build please be linked? > From johan at lodgon.com Sat Jul 6 17:03:01 2019 From: johan at lodgon.com (Johan Vos) Date: Sat, 6 Jul 2019 19:03:01 +0200 Subject: Previews for shared buffer PR In-Reply-To: <1c013f6f-10b7-7410-c490-16452f3872c7@gmail.com> References: <68bf79f7-283c-c465-b424-1da90f72b17a@gmail.com> <1c013f6f-10b7-7410-c490-16452f3872c7@gmail.com> Message-ID: The code for this build comes from the PR source https://github.com/arapte/openjdk-jfx/tree/JDK-8167148-NIO-ByteBuffer (which has changed in the meantime). I'm not sure the error you describe is due to this PR though. Having said that, I agree we need to make sure GTK 2 is still supported. - Johan Op za 6 jul. 2019 om 07:46 schreef Ty Young : > > > On 6/7/19 4:40 AM, Johan Vos wrote: > > The PR discussed in https://github.com/javafxports/openjdk-jfx/pull/472, > > addressing https://bugs.openjdk.java.net/browse/JDK-8167148 provides a > > very > > much wanted feature. It is important that things are done in the right > way > > so that the code can be maintained in the long-term future. > > Therefore, feedback on this PR is extremely important before we can > > consider merging it. Once this PR is merged, there is no easy way back. > It > > is possible to add more functionality, hence my preference is to only > > implement the functionality that is safe and stable, while allowing other > > functionality to be added later or by third-party extensions. (e.g. > > (avoiding) copying from/to GPU) > > > > To make it easier to give feedback, we've build early access versions of > > SDK's including this PR. Note that the PR is not merged, hence not > > available in the regular EA downloads! > > > > If you want to give it a try, download the SDK's from the URL's below. > > There is a test in tests/manual/graphics/PixelBufferPerformanceTest ( > > > https://github.com/arapte/openjdk-jfx/blob/JDK-8167148-NIO-ByteBuffer/tests/manual/graphics/PixelBufferPerformanceTest.java > ) > > that should get you started. > > > > > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_linux-x64_bin-jmods.zip > > > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_linux-x64_bin-sdk.zip > > > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_osx-x64_bin-jmods.zip > > > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_osx-x64_bin-sdk.zip > > > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_windows-x64_bin-jmods.zip > > > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_windows-x64_bin-sdk.zip > > > > - Johan > > > FYI this SDK causes a hard system crash when GTK is set to 2 and/or > prism.forceUploadingPainter is set to true. I don't feel like > purposefully crashing my system to see which of the various combinations > is the issue so forgive me for not providing a more narrowed down cause. > > GTK 2 is still necessary as there are still lingering GTK3 bugs that > have yet to be fixed even in current JavaFX 13. > > prism.forceUploadingPainter is a prism setting that fixes buffer resets > and other various GUI glitching under Linux(an issue I tried reporting a > long time ago) which affects ALL JavaFX applications under Linux but > dramatically increases GPU utilization by 2x-2.5x when doing any kind of > application interaction(resizing, scrolling, etc). Is there a reason > this isn't enabled by default under Linux besides performance? Where is > the documentation for this and other settings? I randomly ran into this > from http://werner.yellowcouch.org/log/javafx-8-command-line-options/ > and was surprised noone really knows about it nor is it documented > anywhere that I can see. > > > Even with GTK 3 this results in a null pointer exception: > > > java.lang.NullPointerException > at > > javafx.graphics/com.sun.prism.es2.ES2SwapChain.createGraphics(ES2SwapChain.java:223) > at > > javafx.graphics/com.sun.prism.es2.ES2SwapChain.createGraphics(ES2SwapChain.java:40) > at > > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:87) > at > > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > at > > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125 > > > Please don't merge this into JDK13 or at least provide a switch to > disable it. This is extremely busted on Linux. > > > Can the source code for this entire JavaFX build please be linked? > > From johan at lodgon.com Sat Jul 6 17:05:07 2019 From: johan at lodgon.com (Johan Vos) Date: Sat, 6 Jul 2019 19:05:07 +0200 Subject: Previews for shared buffer PR In-Reply-To: References: <68bf79f7-283c-c465-b424-1da90f72b17a@gmail.com> <1c013f6f-10b7-7410-c490-16452f3872c7@gmail.com> Message-ID: I agree it would be good to create a new EA version for this feature. I think for this case, it would probably be good if Ambarish could rebase his fork to master, so that we can create a release that includes the changes both in master and in the PR. - Johan Op za 6 jul. 2019 om 18:55 schreef Kevin Rushforth < kevin.rushforth at oracle.com>: > There might be other issues with the early access. The shared NIO buffer > feature should be behavior-neutral if you don't use it. So either there > is some other issue with it, or there is a bug. > > Given the number of changes since that early access, both in the JavaFX > 13 code base and in the PR itself, it seems worth making a new early > access for people to try. I'll also do some local testing both with GTK > 2 and GTK3. > > -- Kevin > > > On 7/5/2019 10:35 PM, Ty Young wrote: > > > > > > On 6/7/19 4:40 AM, Johan Vos wrote: > >> The PR discussed in https://github.com/javafxports/openjdk-jfx/pull/472 > , > >> addressing https://bugs.openjdk.java.net/browse/JDK-8167148 provides > >> a very > >> much wanted feature. It is important that things are done in the > >> right way > >> so that the code can be maintained in the long-term future. > >> Therefore, feedback on this PR is extremely important before we can > >> consider merging it. Once this PR is merged, there is no easy way > >> back. It > >> is possible to add more functionality, hence my preference is to only > >> implement the functionality that is safe and stable, while allowing > >> other > >> functionality to be added later or by third-party extensions. (e.g. > >> (avoiding) copying from/to GPU) > >> > >> To make it easier to give feedback, we've build early access versions of > >> SDK's including this PR. Note that the PR is not merged, hence not > >> available in the regular EA downloads! > >> > >> If you want to give it a try, download the SDK's from the URL's below. > >> There is a test in tests/manual/graphics/PixelBufferPerformanceTest ( > >> > https://github.com/arapte/openjdk-jfx/blob/JDK-8167148-NIO-ByteBuffer/tests/manual/graphics/PixelBufferPerformanceTest.java) > > >> > >> that should get you started. > >> > >> > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_linux-x64_bin-jmods.zip > >> > >> > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_linux-x64_bin-sdk.zip > >> > >> > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_osx-x64_bin-jmods.zip > >> > >> > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_osx-x64_bin-sdk.zip > >> > >> > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_windows-x64_bin-jmods.zip > >> > >> > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_windows-x64_bin-sdk.zip > >> > >> > >> - Johan > > > > > > FYI this SDK causes a hard system crash when GTK is set to 2 and/or > > prism.forceUploadingPainter is set to true. I don't feel like > > purposefully crashing my system to see which of the various > > combinations is the issue so forgive me for not providing a more > > narrowed down cause. > > > > GTK 2 is still necessary as there are still lingering GTK3 bugs that > > have yet to be fixed even in current JavaFX 13. > > > > prism.forceUploadingPainter is a prism setting that fixes buffer > > resets and other various GUI glitching under Linux(an issue I tried > > reporting a long time ago) which affects ALL JavaFX applications under > > Linux but dramatically increases GPU utilization by 2x-2.5x when doing > > any kind of application interaction(resizing, scrolling, etc). Is > > there a reason this isn't enabled by default under Linux besides > > performance? Where is the documentation for this and other settings? I > > randomly ran into this from > > http://werner.yellowcouch.org/log/javafx-8-command-line-options/ and > > was surprised noone really knows about it nor is it documented > > anywhere that I can see. > > > > > > Even with GTK 3 this results in a null pointer exception: > > > > > > java.lang.NullPointerException > > at > > > javafx.graphics/com.sun.prism.es2.ES2SwapChain.createGraphics(ES2SwapChain.java:223) > > at > > > javafx.graphics/com.sun.prism.es2.ES2SwapChain.createGraphics(ES2SwapChain.java:40) > > at > > > javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:87) > > at > > > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > > at > > > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > > at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > > at > > > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > > at > > > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > > at > > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125 > > > > > > Please don't merge this into JDK13 or at least provide a switch to > > disable it. This is extremely busted on Linux. > > > > > > Can the source code for this entire JavaFX build please be linked? > > > > From amnojeeuw at gmail.com Sun Jul 7 10:26:37 2019 From: amnojeeuw at gmail.com (AmnoJeeuw) Date: Sun, 7 Jul 2019 06:26:37 -0400 Subject: JavaFX 12.0.1 - Image ??? Message-ID: <32d8ff2a-9a82-b0cd-5a98-a73dd4f5544b@gmail.com> Windows 8.1 - 64Bit Java --version Openjdk 12.0.1 2019-04-06 OpenJDK Runtime Environment (build 12.0.1+12) OpenJDK 64-Bit Server VM (build 12.0.1+12, mixed mode, sharing) OpenJFX = javafx-sdk-12.0.1 ==================== Is this a bug? Is anyone else experiencing the same issue? Or is it just me who is not smart enough? public void start(Stage primaryStage) throws Exception { MainWindow = primaryStage; // DataIntegrityVerification is a wrapper of StringBuffer var IconLoc = new DataIntegrityVerification(C:\\ArbolOne\\image\\icons\\Icon16x16.png); // Prints "false" var myIconFile = new File(IconLoc.toString()); System.out.println("False = Exist : "+String.valueOf(myIconFile.exists())); // both of these string work var appIcon = new Image( myIconFile.toURI().toString() ); // Displays the right folder name - complete path System.out.println("Image URL is? " + this.appIcon.getUrl()); MainWindow.getIcons().add(appIcon); No errors, but the icon does not display on the top-left corner of the window. --- This email has been checked for viruses by AVG. https://www.avg.com From r.lichtenberger at gmail.com Mon Jul 8 06:13:56 2019 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Mon, 8 Jul 2019 08:13:56 +0200 Subject: Windows (32bit) build problems In-Reply-To: <9164e13d-b3d9-e073-9910-c092255cb93c@videotron.ca> References: <9164e13d-b3d9-e073-9910-c092255cb93c@videotron.ca> Message-ID: <702771e8-c71e-4dfd-0118-64ba140b7f27@gmail.com> Am 05.07.19 um 11:32 schrieb Dan Howard: > You will need Windows 7 or later (Windows 10 is recommended) 64-bit OS I have Windows 7 64-bit OS, but my target platform is Windows 32-bit ;-). From a first cursory look it seems that in win.gradle: def winSdkBinDir = "$WINDOWS_SDK_DIR/Bin" if (WINDOWS_VS_VER != "100") { ??? winSdkBinDir += "/$CPU_BITS" } appends x86 to the winSdkBinDir and thus cannot find rc.exe which is located at C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin and not in C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x86. If I change that to: if (WINDOWS_VS_VER != "100" && IS_64) { ??? winSdkBinDir += "/$CPU_BITS" } gradlew tasks works. Building it still has problems though. I'll try and look into further details, maybe I can come up with a patch that'll make JavaFX compile again on win32. Robert > > > On 7/4/2019 11:01 AM, Robert Lichtenberger wrote: >> Hello everyone, >> >> I try to build JavaFX-12 mods for Windows-32. >> >> For that I cloned http://hg.openjdk.java.net/openjfx/12-dev/rt/ >> (correct?) >> and read the build instructions at >> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Windows >> >> . >> >> First question: >> * The build instructions tell me that gradle 5.3 is used but the >> gradle-wrapper actually downloads 4.8. My guess is that the build >> instructions refer to the current head version. >> * A simple ./gradlew tasks gives the following error: >> >>> * What went wrong: >>> A problem occurred evaluating script. >>>> FAIL: WINSDK_DIR not defined >> There's no such environment variable in the build instructions. By >> looking >> around in win.gradle I guessed that this should point to the "Microsoft >> DirectShow header files", but it is not really well documented. >> I could only make the build continue by patching win.gradle, setting an >> environment variable did not help. >> >> If I add WINDOWS_SDK_DIR="C:\\Program Files\\Microsoft >> SDKs\\Windows\\v7.1" >> in win.gradle right above the checking code, I can execute gradlew >> tasks. >> >> However If I just start gradlew to really build JavaFX I get: >> >> FAILURE: Build failed with an exception. >>> * What went wrong: >>> Execution failed for task ':graphics:compileDecoraNativeShadersWin'. >>>> java.util.concurrent.ExecutionException: >>> org.gradle.process.internal.ExecException: A problem occurred starting >>> process 'command '/VC/BIN/cl.exe'' >>> >> Any help/hints welcome :-) >> From mike.ennen at gmail.com Mon Jul 8 15:47:25 2019 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 8 Jul 2019 08:47:25 -0700 Subject: Review-Request for JDK-8227367 Message-ID: Hi, I'd like to request a review for JDK-8227367 available as a PR on Github: https://github.com/javafxports/openjdk-jfx/pull/518 https://bugs.openjdk.java.net/browse/JDK-8227367 Thanks. -- Michael Ennen From tbee at tbee.org Tue Jul 9 06:44:33 2019 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 9 Jul 2019 08:44:33 +0200 Subject: Table data entry Message-ID: There is a chance that I may need to start a complete rewrite of a Swing client, of course I'm considering JavaFX, but only if I can do efficient data entry in tables. This means: enter commits value and moves focus to another (not necessarily the next) cell. AFAIK one of the requirements is the TableView & CellEditor patch that Jonathan Giles discussed while he was still working at Oracle. I was wondering if that was ever implemented. And if not, why not; it seemed like a doable and highly requested patch. Regards, Tom From jonathan at jonathangiles.net Tue Jul 9 06:49:09 2019 From: jonathan at jonathangiles.net (Jonathan Giles) Date: Tue, 9 Jul 2019 18:49:09 +1200 Subject: Table data entry In-Reply-To: References: Message-ID: It was never merged. It exists somewhere in JBS as a patch file or webrev link. The API was decent (IMHO), but not completely implemented (and nor did everyone agree with my opinion). It worked for simple cases (i.e. ListCell, TreeCell, TableCell, and TreeTableCell), but probably needed more fleshing out to work appropriately in the TableRow and TreeTableRow cases. On Tue, Jul 9, 2019 at 6:45 PM Tom Eugelink wrote: > There is a chance that I may need to start a complete rewrite of a Swing > client, of course I'm considering JavaFX, but only if I can do efficient > data entry in tables. This means: enter commits value and moves focus to > another (not necessarily the next) cell. AFAIK one of the requirements is > the TableView & CellEditor patch that Jonathan Giles discussed while he was > still working at Oracle. I was wondering if that was ever implemented. And > if not, why not; it seemed like a doable and highly requested patch. > > Regards, Tom > > From arunprasad.rajkumar at oracle.com Tue Jul 9 09:14:40 2019 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Tue, 9 Jul 2019 14:44:40 +0530 Subject: [RFR] [openjfx13] 8222912: Websocket client doesn't work in WebView Message-ID: <66FF2926-0587-44D2-9387-B442090E552D@oracle.com> Hi Kevin, Please review the following PR, JBS: https://bugs.openjdk.java.net/browse/JDK-8222912 https://github.com/javafxports/openjdk-jfx/pull/524 Thanks, Arun From arunprasad.rajkumar at oracle.com Tue Jul 9 09:33:06 2019 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Tue, 9 Jul 2019 15:03:06 +0530 Subject: [RFR] [openjfx13] 8227431: [Windows] Fix assertion failure on X86 32-bit when enabling CLOOP based JavaScript interpreter Message-ID: Hi Kevin, Please review the following PR, https://github.com/javafxports/openjdk-jfx/pull/525 Thanks, Arun From kevin.rushforth at oracle.com Tue Jul 9 12:02:19 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 9 Jul 2019 05:02:19 -0700 Subject: Table data entry In-Reply-To: References: Message-ID: The JBS bug is: https://bugs.openjdk.java.net/browse/JDK-8089514 The current status is still as Jonathan described it. This would be a very good enhancement to have, but it will require a fair bit of work to drive consensus on the best way to define and implement this, and then to finish it. -- Kevin On 7/8/2019 11:49 PM, Jonathan Giles wrote: > It was never merged. It exists somewhere in JBS as a patch file or webrev > link. The API was decent (IMHO), but not completely implemented (and nor > did everyone agree with my opinion). It worked for simple cases (i.e. > ListCell, TreeCell, TableCell, and TreeTableCell), but probably needed more > fleshing out to work appropriately in the TableRow and TreeTableRow cases. > > On Tue, Jul 9, 2019 at 6:45 PM Tom Eugelink wrote: > >> There is a chance that I may need to start a complete rewrite of a Swing >> client, of course I'm considering JavaFX, but only if I can do efficient >> data entry in tables. This means: enter commits value and moves focus to >> another (not necessarily the next) cell. AFAIK one of the requirements is >> the TableView & CellEditor patch that Jonathan Giles discussed while he was >> still working at Oracle. I was wondering if that was ever implemented. And >> if not, why not; it seemed like a doable and highly requested patch. >> >> Regards, Tom >> >> From r.lichtenberger at gmail.com Tue Jul 9 14:13:33 2019 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Tue, 9 Jul 2019 16:13:33 +0200 Subject: Windows (32bit) build problems In-Reply-To: <702771e8-c71e-4dfd-0118-64ba140b7f27@gmail.com> References: <9164e13d-b3d9-e073-9910-c092255cb93c@videotron.ca> <702771e8-c71e-4dfd-0118-64ba140b7f27@gmail.com> Message-ID: After restarting from scratch (on a different machine) the build problems described below simply went away :-). So there was probably something in my environment or I changed something inadvertently. Best regards, Robert Am 08.07.19 um 08:13 schrieb Robert Lichtenberger: > Am 05.07.19 um 11:32 schrieb Dan Howard: >> You will need Windows 7 or later (Windows 10 is recommended) 64-bit OS > I have Windows 7 64-bit OS, but my target platform is Windows 32-bit ;-). > > > From a first cursory look it seems that in win.gradle: > > def winSdkBinDir = "$WINDOWS_SDK_DIR/Bin" > if (WINDOWS_VS_VER != "100") { > ??? winSdkBinDir += "/$CPU_BITS" > } > > appends x86 to the winSdkBinDir and thus cannot find rc.exe which is > located at C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin and not in > C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x86. > > If I change that to: > > if (WINDOWS_VS_VER != "100" && IS_64) { > ??? winSdkBinDir += "/$CPU_BITS" > } > > gradlew tasks works. > > Building it still has problems though. I'll try and look into further > details, maybe I can come up with a patch that'll make JavaFX compile > again on win32. > > > Robert > > >> >> On 7/4/2019 11:01 AM, Robert Lichtenberger wrote: >>> Hello everyone, >>> >>> I try to build JavaFX-12 mods for Windows-32. >>> >>> For that I cloned http://hg.openjdk.java.net/openjfx/12-dev/rt/ >>> (correct?) >>> and read the build instructions at >>> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Windows >>> >>> . >>> >>> First question: >>> * The build instructions tell me that gradle 5.3 is used but the >>> gradle-wrapper actually downloads 4.8. My guess is that the build >>> instructions refer to the current head version. >>> * A simple ./gradlew tasks gives the following error: >>> >>>> * What went wrong: >>>> A problem occurred evaluating script. >>>>> FAIL: WINSDK_DIR not defined >>> There's no such environment variable in the build instructions. By >>> looking >>> around in win.gradle I guessed that this should point to the "Microsoft >>> DirectShow header files", but it is not really well documented. >>> I could only make the build continue by patching win.gradle, setting an >>> environment variable did not help. >>> >>> If I add WINDOWS_SDK_DIR="C:\\Program Files\\Microsoft >>> SDKs\\Windows\\v7.1" >>> in win.gradle right above the checking code, I can execute gradlew >>> tasks. >>> >>> However If I just start gradlew to really build JavaFX I get: >>> >>> FAILURE: Build failed with an exception. >>>> * What went wrong: >>>> Execution failed for task ':graphics:compileDecoraNativeShadersWin'. >>>>> java.util.concurrent.ExecutionException: >>>> org.gradle.process.internal.ExecException: A problem occurred starting >>>> process 'command '/VC/BIN/cl.exe'' >>>> >>> Any help/hints welcome :-) >>> > From johan.vos at gluonhq.com Tue Jul 9 15:27:00 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 9 Jul 2019 17:27:00 +0200 Subject: [RFR] JDK-8223760: allow to build static libs Message-ID: Hi Kevin, Please review the following PR: JBS: https://bugs.openjdk.java.net/browse/JDK-8223760 https://github.com/javafxports/openjdk-jfx/pull/470 Thanks, - Johan From alan at whiteware.org Tue Jul 9 17:51:42 2019 From: alan at whiteware.org (Alan White) Date: Tue, 9 Jul 2019 18:51:42 +0100 Subject: Javapackager 10 to bundle OpenJDK 11 runtime In-Reply-To: References: <9A29B02D-FB62-410B-BD2C-B6E82B9F3ADC@whiteware.org> <494d59b2-40f5-7cf6-4efc-8a22bdd7d92f@oracle.com> Message-ID: Hi Johan Been using the gluon packager successfully on windows and macOS, awaiting the release of the JEP343 (I think) one - thank you (from me and my user base)! I just had to renew my Apple developer cert that?s used for signing and discover that Apple have changed the CN in the developer cert from ?Developer ID Application:? to ?Mac Developer:?. Checking https://github.com/johanvos/openjdk-mobile11/blob/packager/src/jdk.packager/macosx/classes/jdk/packager/internal/mac/MacAppBundler.java I see the CN prefix is hard-coded, so my options appear to be fork, edit rebuild. Anyone aware of any other options, or is now the time to switch to the early access jpackage plse? Thanks Alan > On 19 Dec 2018, at 18:10, Johan Vos wrote: > > The packager that works with Java 11 and JavaFX 11 is at > > http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.ziphttp://download2.gluonhq.com/jpackager/11/jdk.packager-osx.ziphttp://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip > > (see > http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022500.html > ). > > However, I highly recommend testing the early access version of jpackage. > That is the way forward for the packager. > > - Johan > > > On Wed, Dec 19, 2018 at 6:36 PM Kevin Rushforth > wrote: > >> I doubt that will work. >> >> We are developing a replacement tool, jpackage [1], which will be part >> of OpenJDK. It is planned for JDK 13, and will support JDK 11 or later >> as a Java runtime. You can download an early access of this tool on >> jdk.java.net [2]. Discussion on jpackage is happening on the >> core-libs-dev mailing list [3]. Alternatively, Gluon has a standalone >> version of javapackager that will work with JDK 11. Johan Vos can >> provide a pointer. >> >> -- Kevin >> >> [1] https://openjdk.java.net/jeps/343 >> [2] http://jdk.java.net/jpackage/ >> [3] http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev >> >> On 12/19/2018 5:28 AM, Alan White (Drum Score Editor) wrote: >>> I understand the guidance for apps created with OpenJDK 11, is to use >> the javapackager from jdk 10. >>> >>> The old basedir parameter that could be used to direct the packager to >> use a specific runtime is no longer present. >>> >>> Is there any mechanism I?ve missed in order to have the packager from >> jdk10 bundle the 11 runtime plse? >>> >>> Thanks >> >> From kevin.rushforth at oracle.com Tue Jul 9 18:04:21 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 9 Jul 2019 11:04:21 -0700 Subject: OpenJFX 13 is in Rampdown Phase One (RDP1) Message-ID: OpenJFX 13 is now in Rampdown Phase One RDP1 [1]. We have forked a new jfx-13/rt repo [2] for stabilizing the OpenJFX 13 release. Here is the short summary of what this means: - The openjfx/13-dev/rt repo is now open for pushing changesets for FX 13 that meet the RDP1 criteria as outlined below. - The openjfx/jfx-dev/rt repo is available for pushing bug fixes or enhancements for FX 14. - I will periodically sync 13-dev --> jfx-dev (meaning that developers should push to one or the other, not both) - The develop branch of the javafxports/openjdk-jfx GitHub sandbox may be used for either FX 13 or FX 14 changes During RDP1, the only restriction is that any enhancements will need explicit approval to go into openjfx13, although most enhancements should be retargeted to openjfx14 now. Note that these restrictions apply only to the forked 13-dev/rt repo. The jfx-dev/rt repo is open for openjfx14 fixes. We will use the same rules for RDP1 that the JDK uses [3], with the same three modifications we did for the previous release: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 13 release. As an obvious choice, derived from the JBS fix version, we will use "openjfx13-enhancement-request", "openjfx13-enhancement-yes", "openjfx13-enhancement-no" and "openjfx13-enhancement-nmi" as corresponding labels. 3. No explicit approval is needed to push P4 bugs to jfx-13/rt during RDP1, as long as those bugs have otherwise met the usual code review criteria. Having said that, most P4 bugs should now go into jfx-dev for openjfx14, since we do not want to risk anything that would destabilize the openjfx13 release without a compelling reason. Also, we have less than 4 weeks until RDP2 of openjfx13 and we would be better served fixing higher priority bugs. Note that doc bugs and test bugs of any priority are fine to fix for openjfx13 during this time. Let me know if there are any questions. -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2019-June/023385.html [2] http://hg.openjdk.java.net/openjfx/13-dev/rt [3] http://openjdk.java.net/jeps/3 From kevin.rushforth at oracle.com Tue Jul 9 18:16:07 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 9 Jul 2019 11:16:07 -0700 Subject: [14] RFR: JDK-8226365: Change JavaFX release version to 14 Message-ID: <5ce42b46-db4c-f60c-0eed-823eef54366f@oracle.com> Please review the following to bump the JavaFX release version in jfx-dev to 14: https://bugs.openjdk.java.net/browse/JDK-8226365 https://github.com/javafxports/openjdk-jfx/pull/523 -- Kevin From alan at whiteware.org Tue Jul 9 18:16:51 2019 From: alan at whiteware.org (Alan White) Date: Tue, 9 Jul 2019 19:16:51 +0100 Subject: Javapackager 10 to bundle OpenJDK 11 runtime In-Reply-To: References: <9A29B02D-FB62-410B-BD2C-B6E82B9F3ADC@whiteware.org> <494d59b2-40f5-7cf6-4efc-8a22bdd7d92f@oracle.com> Message-ID: <716E9FD8-7778-4ADD-ABAB-909C36E82300@whiteware.org> Apologies for the spam. This was my issue, I got confused renewing my certs, as to which one did what. Apple have not changed the prefix, and despite warnings about notarising, it seems to all work. Just wish there weren?t so many cert types flying around to sign an app! Meantime, crisis over and patch distributed, I?ll work to migrate to jpackage. Thanks Alan > On 9 Jul 2019, at 18:51, Alan White wrote: > > Hi Johan > > Been using the gluon packager successfully on windows and macOS, awaiting the release of the JEP343 (I think) one - thank you (from me and my user base)! > > I just had to renew my Apple developer cert that?s used for signing and discover that Apple have changed the CN in the developer cert from ?Developer ID Application:? to ?Mac Developer:?. Checking https://github.com/johanvos/openjdk-mobile11/blob/packager/src/jdk.packager/macosx/classes/jdk/packager/internal/mac/MacAppBundler.java I see the CN prefix is hard-coded, so my options appear to be fork, edit rebuild. > > Anyone aware of any other options, or is now the time to switch to the early access jpackage plse? > > Thanks > Alan > >> On 19 Dec 2018, at 18:10, Johan Vos > wrote: >> >> The packager that works with Java 11 and JavaFX 11 is at >> >> http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.ziphttp://download2.gluonhq.com/jpackager/11/jdk.packager-osx.ziphttp://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip >> >> (see >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022500.html >> ). >> >> However, I highly recommend testing the early access version of jpackage. >> That is the way forward for the packager. >> >> - Johan >> >> >> On Wed, Dec 19, 2018 at 6:36 PM Kevin Rushforth >> wrote: >> >>> I doubt that will work. >>> >>> We are developing a replacement tool, jpackage [1], which will be part >>> of OpenJDK. It is planned for JDK 13, and will support JDK 11 or later >>> as a Java runtime. You can download an early access of this tool on >>> jdk.java.net [2]. Discussion on jpackage is happening on the >>> core-libs-dev mailing list [3]. Alternatively, Gluon has a standalone >>> version of javapackager that will work with JDK 11. Johan Vos can >>> provide a pointer. >>> >>> -- Kevin >>> >>> [1] https://openjdk.java.net/jeps/343 >>> [2] http://jdk.java.net/jpackage/ >>> [3] http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev >>> >>> On 12/19/2018 5:28 AM, Alan White (Drum Score Editor) wrote: >>>> I understand the guidance for apps created with OpenJDK 11, is to use >>> the javapackager from jdk 10. >>>> >>>> The old basedir parameter that could be used to direct the packager to >>> use a specific runtime is no longer present. >>>> >>>> Is there any mechanism I?ve missed in order to have the packager from >>> jdk10 bundle the 11 runtime plse? >>>> >>>> Thanks >>> >>> > From nlisker at gmail.com Tue Jul 9 19:56:53 2019 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 9 Jul 2019 22:56:53 +0300 Subject: Review Request: JDK-8226850: Use an EnumSet for DirtyBits instead of an ordinal-based mask Message-ID: Hi Kevin/Ambarish, Please review the simple fix for: https://bugs.openjdk.java.net/browse/JDK-8226850 http://cr.openjdk.java.net/~nlisker/8226850/webrev.00/ Thanks, Nir From kevin.rushforth at oracle.com Wed Jul 10 18:35:48 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Jul 2019 11:35:48 -0700 Subject: [14] RFR: JDK-8227540: Add README.md and CONTRIBUTING.md to jfx repo Message-ID: Please review the following: https://bugs.openjdk.java.net/browse/JDK-8227540 https://github.com/javafxports/openjdk-jfx/pull/526 Details are in the PR. -- Kevin From kevin.rushforth at oracle.com Fri Jul 12 01:01:43 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 11 Jul 2019 18:01:43 -0700 Subject: [14] RFR: JDK-8193911: Create README file to document bumping the version number Message-ID: <3bf88722-90a4-28dd-dc8c-0d53dedeb258@oracle.com> Ambarish and Johan, Please review the following to add instructions for bumping the JavaFX release version number: https://bugs.openjdk.java.net/browse/JDK-8193911 https://github.com/javafxports/openjdk-jfx/pull/527 Thanks. -- Kevin From nlisker at gmail.com Sat Jul 13 23:51:39 2019 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 14 Jul 2019 02:51:39 +0300 Subject: Ubuntu build instructions Message-ID: Hi, I'm trying to build OpenJFX on Ubuntu 18.04 and it seems that the instructions are out of date [1]. I'm getting an error that says that libgstreamer0.10-dev and libgstreamer-plugins-base0.10-dev can't be found when executing sudo apt-get install. Can the instructions be updated? - Nir [1] https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Ubuntu16.04 From kevin.rushforth at oracle.com Mon Jul 15 15:09:37 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 Jul 2019 08:09:37 -0700 Subject: Result: New OpenJFX Committer: Nir Lisker Message-ID: <029a2a39-68c3-f795-90e9-0e156a40f1eb@oracle.com> Voting for Nir Lisker [1] to OpenJFX Committer [2] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] http://openjdk.java.net/census#nlisker [2] https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-June/023391.html From sproket at videotron.ca Wed Jul 17 02:09:57 2019 From: sproket at videotron.ca (Dan Howard) Date: Tue, 16 Jul 2019 22:09:57 -0400 Subject: Result: New OpenJFX Committer: Nir Lisker In-Reply-To: References: Message-ID: <536162cc-49e4-e5d4-6f77-a1d1ab82c5b8@videotron.ca> Cool On 7/15/2019 11:09 AM, Kevin Rushforth wrote: > Voting for Nir Lisker [1] to OpenJFX Committer [2] is now closed. > > Yes: 6 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Lazy Consensus, this is > sufficient to approve the nomination. > > -- Kevin > > [1] http://openjdk.java.net/census#nlisker > [2] > https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-June/023391.html > > From johan.vos at gluonhq.com Wed Jul 17 13:42:40 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 17 Jul 2019 15:42:40 +0200 Subject: New preview release for shared buffer PR Message-ID: Hi, A new early access release containing the code in PR 472 is now available (see links below). (https://github.com/javafxports/openjdk-jfx/pull/472) This EA release takes into account all discussions on the PR so far. It would be great to have this in JavaFX 13, and therefore it is very important to have it tested as much as possible. Feedback welcome at https://github.com/javafxports/openjdk-jfx/pull/472 Thanks, - Johan https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+10_osx-x64_bin-jmods.zip https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+10_osx-x64_bin-sdk.zip https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+10_linux-x64_bin-jmods.zip https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+10_linux-x64_bin-sdk.zip https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+10_windows-x64_bin-jmods.zip https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+10_windows-x64_bin-sdk.zip From r.lichtenberger at gmail.com Wed Jul 17 14:38:01 2019 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Wed, 17 Jul 2019 16:38:01 +0200 Subject: Debugging JavaFX Message-ID: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> I'm trying to get to the bottom of some weird layout problems in my application. To that end I want/need to debug JavaFX classes. But when I step into JavaFX classes I don't see local variables or parameter names. So I thought debug symbols are probably stripped from the official builds. I rolled my own and tried ??? CONF = Debug and ??? CONF = DebugNative in gradle.properties, recompiled OpenJFX and integrated the libraries into a little eclipse testproject. But I still don't see parameter names or local variables. Is there something else I need to do in order to see them? Best regards, Robert From kevin.rushforth at oracle.com Wed Jul 17 14:45:53 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 17 Jul 2019 07:45:53 -0700 Subject: Debugging JavaFX In-Reply-To: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> References: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> Message-ID: <715f1ed4-d5b7-7dab-fac9-5f436e71c0a2@oracle.com> That should have been enough to enable local variable symbols. We have the following logic for JavaCompile tasks: ??????? compile.options.debugOptions.debugLevel = IS_DEBUG_JAVA ? "source,lines,vars" : "source,lines" IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. Maybe something else is stripping out the symbols. Has anyone else debugged JavaFX recently and tried to look at local vars? If not, I'll take a quick look later today. -- Kevin On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: > I'm trying to get to the bottom of some weird layout problems in my > application. > > To that end I want/need to debug JavaFX classes. > > But when I step into JavaFX classes I don't see local variables or > parameter names. > > So I thought debug symbols are probably stripped from the official builds. > > I rolled my own and tried > > ??? CONF = Debug > > and > > ??? CONF = DebugNative > > in gradle.properties, recompiled OpenJFX and integrated the libraries > into a little eclipse testproject. > > But I still don't see parameter names or local variables. > > Is there something else I need to do in order to see them? > > > Best regards, > > Robert > > From mp at jugs.org Wed Jul 17 14:56:39 2019 From: mp at jugs.org (Michael Paus) Date: Wed, 17 Jul 2019 16:56:39 +0200 Subject: Debugging JavaFX In-Reply-To: <715f1ed4-d5b7-7dab-fac9-5f436e71c0a2@oracle.com> References: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> <715f1ed4-d5b7-7dab-fac9-5f436e71c0a2@oracle.com> Message-ID: <2e33341d-0eea-27ba-45f8-5d6cc6e9e217@jugs.org> Hi, I don't see any problem of that kind with Eclipse, on MacOS, JavaFX 13-ea 9 via Maven. Michael Am 17.07.19 um 16:45 schrieb Kevin Rushforth: > That should have been enough to enable local variable symbols. We have > the following logic for JavaCompile tasks: > > ??????? compile.options.debugOptions.debugLevel = IS_DEBUG_JAVA ? > "source,lines,vars" : "source,lines" > > IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. > > Maybe something else is stripping out the symbols. > > Has anyone else debugged JavaFX recently and tried to look at local > vars? If not, I'll take a quick look later today. > > -- Kevin > > > > On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: >> I'm trying to get to the bottom of some weird layout problems in my >> application. >> >> To that end I want/need to debug JavaFX classes. >> >> But when I step into JavaFX classes I don't see local variables or >> parameter names. >> >> So I thought debug symbols are probably stripped from the official >> builds. >> >> I rolled my own and tried >> >> ???? CONF = Debug >> >> and >> >> ???? CONF = DebugNative >> >> in gradle.properties, recompiled OpenJFX and integrated the libraries >> into a little eclipse testproject. >> >> But I still don't see parameter names or local variables. >> >> Is there something else I need to do in order to see them? >> >> >> Best regards, >> >> Robert >> >> > From kevin.rushforth at oracle.com Wed Jul 17 15:01:22 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 17 Jul 2019 08:01:22 -0700 Subject: Debugging JavaFX In-Reply-To: <2e33341d-0eea-27ba-45f8-5d6cc6e9e217@jugs.org> References: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> <715f1ed4-d5b7-7dab-fac9-5f436e71c0a2@oracle.com> <2e33341d-0eea-27ba-45f8-5d6cc6e9e217@jugs.org> Message-ID: When you say that don't see a problem, what exactly do you mean? If you are able to see the local variables in a production build, then that would in fact be surprising. The production builds, including EA builds, should be being built with "-PCONF=Release" which would exclude vars. Someone from Gluon should confirm. -- Kevin On 7/17/2019 7:56 AM, Michael Paus wrote: > Hi, > I don't see any problem of that kind with Eclipse, on MacOS, JavaFX > 13-ea 9 via Maven. > Michael > > Am 17.07.19 um 16:45 schrieb Kevin Rushforth: >> That should have been enough to enable local variable symbols. We >> have the following logic for JavaCompile tasks: >> >> ??????? compile.options.debugOptions.debugLevel = IS_DEBUG_JAVA ? >> "source,lines,vars" : "source,lines" >> >> IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. >> >> Maybe something else is stripping out the symbols. >> >> Has anyone else debugged JavaFX recently and tried to look at local >> vars? If not, I'll take a quick look later today. >> >> -- Kevin >> >> >> >> On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: >>> I'm trying to get to the bottom of some weird layout problems in my >>> application. >>> >>> To that end I want/need to debug JavaFX classes. >>> >>> But when I step into JavaFX classes I don't see local variables or >>> parameter names. >>> >>> So I thought debug symbols are probably stripped from the official >>> builds. >>> >>> I rolled my own and tried >>> >>> ???? CONF = Debug >>> >>> and >>> >>> ???? CONF = DebugNative >>> >>> in gradle.properties, recompiled OpenJFX and integrated the libraries >>> into a little eclipse testproject. >>> >>> But I still don't see parameter names or local variables. >>> >>> Is there something else I need to do in order to see them? >>> >>> >>> Best regards, >>> >>> Robert >>> >>> >> > > From mp at jugs.org Wed Jul 17 15:21:59 2019 From: mp at jugs.org (Michael Paus) Date: Wed, 17 Jul 2019 17:21:59 +0200 Subject: Debugging JavaFX In-Reply-To: References: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> <715f1ed4-d5b7-7dab-fac9-5f436e71c0a2@oracle.com> <2e33341d-0eea-27ba-45f8-5d6cc6e9e217@jugs.org> Message-ID: Oh I see. I should have read the text more carefully. I confused local with internal variables. I can indeed not see variables with a local scope inside a method and I also don't see the names of parameters. They are named arg0, ... but I do see their values. This behaviour seems to be different to the JDK sources. Am 17.07.19 um 17:01 schrieb Kevin Rushforth: > When you say that don't see a problem, what exactly do you mean? If > you are able to see the local variables in a production build, then > that would in fact be surprising. The production builds, including EA > builds, should be being built with "-PCONF=Release" which would > exclude vars. Someone from Gluon should confirm. > > -- Kevin > > > On 7/17/2019 7:56 AM, Michael Paus wrote: >> Hi, >> I don't see any problem of that kind with Eclipse, on MacOS, JavaFX >> 13-ea 9 via Maven. >> Michael >> >> Am 17.07.19 um 16:45 schrieb Kevin Rushforth: >>> That should have been enough to enable local variable symbols. We >>> have the following logic for JavaCompile tasks: >>> >>> ??????? compile.options.debugOptions.debugLevel = IS_DEBUG_JAVA ? >>> "source,lines,vars" : "source,lines" >>> >>> IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. >>> >>> Maybe something else is stripping out the symbols. >>> >>> Has anyone else debugged JavaFX recently and tried to look at local >>> vars? If not, I'll take a quick look later today. >>> >>> -- Kevin >>> >>> >>> >>> On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: >>>> I'm trying to get to the bottom of some weird layout problems in my >>>> application. >>>> >>>> To that end I want/need to debug JavaFX classes. >>>> >>>> But when I step into JavaFX classes I don't see local variables or >>>> parameter names. >>>> >>>> So I thought debug symbols are probably stripped from the official >>>> builds. >>>> >>>> I rolled my own and tried >>>> >>>> ???? CONF = Debug >>>> >>>> and >>>> >>>> ???? CONF = DebugNative >>>> >>>> in gradle.properties, recompiled OpenJFX and integrated the libraries >>>> into a little eclipse testproject. >>>> >>>> But I still don't see parameter names or local variables. >>>> >>>> Is there something else I need to do in order to see them? >>>> >>>> >>>> Best regards, >>>> >>>> Robert >>>> >>>> >>> >> >> > From tom.schindl at bestsolution.at Wed Jul 17 16:57:06 2019 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 17 Jul 2019 18:57:06 +0200 Subject: Debugging JavaFX In-Reply-To: References: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> <715f1ed4-d5b7-7dab-fac9-5f436e71c0a2@oracle.com> <2e33341d-0eea-27ba-45f8-5d6cc6e9e217@jugs.org> Message-ID: <05bc0108-7f82-0bb1-6026-83c082294919@bestsolution.at> so what is the reason to strip them (i guess it it size) it is extremely painful to don't see local-variables, have parameter names, arg1,arg2, ... . Tom On 17.07.19 17:01, Kevin Rushforth wrote: > When you say that don't see a problem, what exactly do you mean? If you > are able to see the local variables in a production build, then that > would in fact be surprising. The production builds, including EA builds, > should be being built with "-PCONF=Release" which would exclude vars. > Someone from Gluon should confirm. > > -- Kevin > > > On 7/17/2019 7:56 AM, Michael Paus wrote: >> Hi, >> I don't see any problem of that kind with Eclipse, on MacOS, JavaFX >> 13-ea 9 via Maven. >> Michael >> >> Am 17.07.19 um 16:45 schrieb Kevin Rushforth: >>> That should have been enough to enable local variable symbols. We >>> have the following logic for JavaCompile tasks: >>> >>> ??????? compile.options.debugOptions.debugLevel = IS_DEBUG_JAVA ? >>> "source,lines,vars" : "source,lines" >>> >>> IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. >>> >>> Maybe something else is stripping out the symbols. >>> >>> Has anyone else debugged JavaFX recently and tried to look at local >>> vars? If not, I'll take a quick look later today. >>> >>> -- Kevin >>> >>> >>> >>> On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: >>>> I'm trying to get to the bottom of some weird layout problems in my >>>> application. >>>> >>>> To that end I want/need to debug JavaFX classes. >>>> >>>> But when I step into JavaFX classes I don't see local variables or >>>> parameter names. >>>> >>>> So I thought debug symbols are probably stripped from the official >>>> builds. >>>> >>>> I rolled my own and tried >>>> >>>> ???? CONF = Debug >>>> >>>> and >>>> >>>> ???? CONF = DebugNative >>>> >>>> in gradle.properties, recompiled OpenJFX and integrated the libraries >>>> into a little eclipse testproject. >>>> >>>> But I still don't see parameter names or local variables. >>>> >>>> Is there something else I need to do in order to see them? >>>> >>>> >>>> Best regards, >>>> >>>> Robert >>>> >>>> >>> >> >> > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From kevin.rushforth at oracle.com Wed Jul 17 17:12:42 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 17 Jul 2019 10:12:42 -0700 Subject: Debugging JavaFX In-Reply-To: <05bc0108-7f82-0bb1-6026-83c082294919@bestsolution.at> References: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> <715f1ed4-d5b7-7dab-fac9-5f436e71c0a2@oracle.com> <2e33341d-0eea-27ba-45f8-5d6cc6e9e217@jugs.org> <05bc0108-7f82-0bb1-6026-83c082294919@bestsolution.at> Message-ID: Mainly size. Generally if a developer is going to debug JavaFX to point of wanting to look at local variables, it doesn't seem a stretch for them to build JavaFX. -- Kevin On 7/17/2019 9:57 AM, Tom Schindl wrote: > so what is the reason to strip them (i guess it it size) it is extremely > painful to don't see local-variables, have parameter names, arg1,arg2, ... . > > Tom > > On 17.07.19 17:01, Kevin Rushforth wrote: >> When you say that don't see a problem, what exactly do you mean? If you >> are able to see the local variables in a production build, then that >> would in fact be surprising. The production builds, including EA builds, >> should be being built with "-PCONF=Release" which would exclude vars. >> Someone from Gluon should confirm. >> >> -- Kevin >> >> >> On 7/17/2019 7:56 AM, Michael Paus wrote: >>> Hi, >>> I don't see any problem of that kind with Eclipse, on MacOS, JavaFX >>> 13-ea 9 via Maven. >>> Michael >>> >>> Am 17.07.19 um 16:45 schrieb Kevin Rushforth: >>>> That should have been enough to enable local variable symbols. We >>>> have the following logic for JavaCompile tasks: >>>> >>>> ??????? compile.options.debugOptions.debugLevel = IS_DEBUG_JAVA ? >>>> "source,lines,vars" : "source,lines" >>>> >>>> IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. >>>> >>>> Maybe something else is stripping out the symbols. >>>> >>>> Has anyone else debugged JavaFX recently and tried to look at local >>>> vars? If not, I'll take a quick look later today. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: >>>>> I'm trying to get to the bottom of some weird layout problems in my >>>>> application. >>>>> >>>>> To that end I want/need to debug JavaFX classes. >>>>> >>>>> But when I step into JavaFX classes I don't see local variables or >>>>> parameter names. >>>>> >>>>> So I thought debug symbols are probably stripped from the official >>>>> builds. >>>>> >>>>> I rolled my own and tried >>>>> >>>>> ???? CONF = Debug >>>>> >>>>> and >>>>> >>>>> ???? CONF = DebugNative >>>>> >>>>> in gradle.properties, recompiled OpenJFX and integrated the libraries >>>>> into a little eclipse testproject. >>>>> >>>>> But I still don't see parameter names or local variables. >>>>> >>>>> Is there something else I need to do in order to see them? >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Robert >>>>> >>>>> >>> From tom.schindl at bestsolution.at Wed Jul 17 19:01:22 2019 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 17 Jul 2019 21:01:22 +0200 Subject: Debugging JavaFX In-Reply-To: References: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> <715f1ed4-d5b7-7dab-fac9-5f436e71c0a2@oracle.com> <2e33341d-0eea-27ba-45f8-5d6cc6e9e217@jugs.org> <05bc0108-7f82-0bb1-6026-83c082294919@bestsolution.at> Message-ID: Well the main problem is that if there are no local var you can not set conditional break points in the code, inject syserr logging to understand what is going on and what your code does to FX. One could provide 2 artifacts one with and one without debug symbols. Tom On 17.07.19 19:12, Kevin Rushforth wrote: > Mainly size. Generally if a developer is going to debug JavaFX to point > of wanting to look at local variables, it doesn't seem a stretch for > them to build JavaFX. > > -- Kevin > > > On 7/17/2019 9:57 AM, Tom Schindl wrote: >> so what is the reason to strip them (i guess it it size) it is extremely >> painful to don't see local-variables, have parameter names, arg1,arg2, >> ... . >> >> Tom >> >> On 17.07.19 17:01, Kevin Rushforth wrote: >>> When you say that don't see a problem, what exactly do you mean? If you >>> are able to see the local variables in a production build, then that >>> would in fact be surprising. The production builds, including EA builds, >>> should be being built with "-PCONF=Release" which would exclude vars. >>> Someone from Gluon should confirm. >>> >>> -- Kevin >>> >>> >>> On 7/17/2019 7:56 AM, Michael Paus wrote: >>>> Hi, >>>> I don't see any problem of that kind with Eclipse, on MacOS, JavaFX >>>> 13-ea 9 via Maven. >>>> Michael >>>> >>>> Am 17.07.19 um 16:45 schrieb Kevin Rushforth: >>>>> That should have been enough to enable local variable symbols. We >>>>> have the following logic for JavaCompile tasks: >>>>> >>>>> ???????? compile.options.debugOptions.debugLevel = IS_DEBUG_JAVA ? >>>>> "source,lines,vars" : "source,lines" >>>>> >>>>> IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. >>>>> >>>>> Maybe something else is stripping out the symbols. >>>>> >>>>> Has anyone else debugged JavaFX recently and tried to look at local >>>>> vars? If not, I'll take a quick look later today. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: >>>>>> I'm trying to get to the bottom of some weird layout problems in my >>>>>> application. >>>>>> >>>>>> To that end I want/need to debug JavaFX classes. >>>>>> >>>>>> But when I step into JavaFX classes I don't see local variables or >>>>>> parameter names. >>>>>> >>>>>> So I thought debug symbols are probably stripped from the official >>>>>> builds. >>>>>> >>>>>> I rolled my own and tried >>>>>> >>>>>> ????? CONF = Debug >>>>>> >>>>>> and >>>>>> >>>>>> ????? CONF = DebugNative >>>>>> >>>>>> in gradle.properties, recompiled OpenJFX and integrated the libraries >>>>>> into a little eclipse testproject. >>>>>> >>>>>> But I still don't see parameter names or local variables. >>>>>> >>>>>> Is there something else I need to do in order to see them? >>>>>> >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Robert >>>>>> >>>>>> >>>> > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From tbee at tbee.org Wed Jul 17 20:50:54 2019 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 17 Jul 2019 22:50:54 +0200 Subject: Debugging JavaFX In-Reply-To: References: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> <715f1ed4-d5b7-7dab-fac9-5f436e71c0a2@oracle.com> <2e33341d-0eea-27ba-45f8-5d6cc6e9e217@jugs.org> <05bc0108-7f82-0bb1-6026-83c082294919@bestsolution.at> Message-ID: I think I saw that one of the argument for not providing debug symbols was size... If there is anything I would not quickly compromise on nowadays is size. Even my smartwatch has gigabytes of internal storage. If size is an issue for an application, it is usually not caused by including debug symbols in a jar. On 17-7-2019 21:01, Tom Schindl wrote: > Well the main problem is that if there are no local var you can not set > conditional break points in the code, inject syserr logging to > understand what is going on and what your code does to FX. > > One could provide 2 artifacts one with and one without debug symbols. > > Tom > > On 17.07.19 19:12, Kevin Rushforth wrote: >> Mainly size. Generally if a developer is going to debug JavaFX to point >> of wanting to look at local variables, it doesn't seem a stretch for >> them to build JavaFX. >> >> -- Kevin >> >> >> On 7/17/2019 9:57 AM, Tom Schindl wrote: >>> so what is the reason to strip them (i guess it it size) it is extremely >>> painful to don't see local-variables, have parameter names, arg1,arg2, >>> ... . >>> >>> Tom >>> >>> On 17.07.19 17:01, Kevin Rushforth wrote: >>>> When you say that don't see a problem, what exactly do you mean? If you >>>> are able to see the local variables in a production build, then that >>>> would in fact be surprising. The production builds, including EA builds, >>>> should be being built with "-PCONF=Release" which would exclude vars. >>>> Someone from Gluon should confirm. >>>> >>>> -- Kevin >>>> >>>> >>>> On 7/17/2019 7:56 AM, Michael Paus wrote: >>>>> Hi, >>>>> I don't see any problem of that kind with Eclipse, on MacOS, JavaFX >>>>> 13-ea 9 via Maven. >>>>> Michael >>>>> >>>>> Am 17.07.19 um 16:45 schrieb Kevin Rushforth: >>>>>> That should have been enough to enable local variable symbols. We >>>>>> have the following logic for JavaCompile tasks: >>>>>> >>>>>> ???????? compile.options.debugOptions.debugLevel = IS_DEBUG_JAVA ? >>>>>> "source,lines,vars" : "source,lines" >>>>>> >>>>>> IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. >>>>>> >>>>>> Maybe something else is stripping out the symbols. >>>>>> >>>>>> Has anyone else debugged JavaFX recently and tried to look at local >>>>>> vars? If not, I'll take a quick look later today. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: >>>>>>> I'm trying to get to the bottom of some weird layout problems in my >>>>>>> application. >>>>>>> >>>>>>> To that end I want/need to debug JavaFX classes. >>>>>>> >>>>>>> But when I step into JavaFX classes I don't see local variables or >>>>>>> parameter names. >>>>>>> >>>>>>> So I thought debug symbols are probably stripped from the official >>>>>>> builds. >>>>>>> >>>>>>> I rolled my own and tried >>>>>>> >>>>>>> ????? CONF = Debug >>>>>>> >>>>>>> and >>>>>>> >>>>>>> ????? CONF = DebugNative >>>>>>> >>>>>>> in gradle.properties, recompiled OpenJFX and integrated the libraries >>>>>>> into a little eclipse testproject. >>>>>>> >>>>>>> But I still don't see parameter names or local variables. >>>>>>> >>>>>>> Is there something else I need to do in order to see them? >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Robert >>>>>>> >>>>>>> From kevin.rushforth at oracle.com Wed Jul 17 22:03:49 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 17 Jul 2019 15:03:49 -0700 Subject: Debugging JavaFX In-Reply-To: References: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> <715f1ed4-d5b7-7dab-fac9-5f436e71c0a2@oracle.com> <2e33341d-0eea-27ba-45f8-5d6cc6e9e217@jugs.org> <05bc0108-7f82-0bb1-6026-83c082294919@bestsolution.at> Message-ID: I did a quick test and the difference in size is noticeable, but not huge -- on the order of 10% larger with the local symbols. You could file an enhancement to have a binary available with the local symbols (or to add them to the default build), but I don't know whether it's generally useful enough to justify it. Maybe Johan can weigh in on this one? -- Kevin On 7/17/2019 1:50 PM, Tom Eugelink wrote: > I think I saw that one of the argument for not providing debug symbols > was size... If there is anything I would not quickly compromise on > nowadays is size. Even my smartwatch has gigabytes of internal > storage. If size is an issue for an application, it is usually not > caused by including debug symbols in a jar. > > > On 17-7-2019 21:01, Tom Schindl wrote: >> Well the main problem is that if there are no local var you can not set >> conditional break points in the code, inject syserr logging to >> understand what is going on and what your code does to FX. >> >> One could provide 2 artifacts one with and one without debug symbols. >> >> Tom >> >> On 17.07.19 19:12, Kevin Rushforth wrote: >>> Mainly size. Generally if a developer is going to debug JavaFX to point >>> of wanting to look at local variables, it doesn't seem a stretch for >>> them to build JavaFX. >>> >>> -- Kevin >>> >>> >>> On 7/17/2019 9:57 AM, Tom Schindl wrote: >>>> so what is the reason to strip them (i guess it it size) it is >>>> extremely >>>> painful to don't see local-variables, have parameter names, arg1,arg2, >>>> ... . >>>> >>>> Tom >>>> >>>> On 17.07.19 17:01, Kevin Rushforth wrote: >>>>> When you say that don't see a problem, what exactly do you mean? >>>>> If you >>>>> are able to see the local variables in a production build, then that >>>>> would in fact be surprising. The production builds, including EA >>>>> builds, >>>>> should be being built with "-PCONF=Release" which would exclude vars. >>>>> Someone from Gluon should confirm. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 7/17/2019 7:56 AM, Michael Paus wrote: >>>>>> Hi, >>>>>> I don't see any problem of that kind with Eclipse, on MacOS, JavaFX >>>>>> 13-ea 9 via Maven. >>>>>> Michael >>>>>> >>>>>> Am 17.07.19 um 16:45 schrieb Kevin Rushforth: >>>>>>> That should have been enough to enable local variable symbols. We >>>>>>> have the following logic for JavaCompile tasks: >>>>>>> >>>>>>> ????????? compile.options.debugOptions.debugLevel = IS_DEBUG_JAVA ? >>>>>>> "source,lines,vars" : "source,lines" >>>>>>> >>>>>>> IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. >>>>>>> >>>>>>> Maybe something else is stripping out the symbols. >>>>>>> >>>>>>> Has anyone else debugged JavaFX recently and tried to look at local >>>>>>> vars? If not, I'll take a quick look later today. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: >>>>>>>> I'm trying to get to the bottom of some weird layout problems >>>>>>>> in my >>>>>>>> application. >>>>>>>> >>>>>>>> To that end I want/need to debug JavaFX classes. >>>>>>>> >>>>>>>> But when I step into JavaFX classes I don't see local variables or >>>>>>>> parameter names. >>>>>>>> >>>>>>>> So I thought debug symbols are probably stripped from the official >>>>>>>> builds. >>>>>>>> >>>>>>>> I rolled my own and tried >>>>>>>> >>>>>>>> ?????? CONF = Debug >>>>>>>> >>>>>>>> and >>>>>>>> >>>>>>>> ?????? CONF = DebugNative >>>>>>>> >>>>>>>> in gradle.properties, recompiled OpenJFX and integrated the >>>>>>>> libraries >>>>>>>> into a little eclipse testproject. >>>>>>>> >>>>>>>> But I still don't see parameter names or local variables. >>>>>>>> >>>>>>>> Is there something else I need to do in order to see them? >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Robert >>>>>>>> >>>>>>>> > From pedro.duquevieira at gmail.com Wed Jul 17 23:58:17 2019 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 18 Jul 2019 00:58:17 +0100 Subject: Debugging JavaFX Message-ID: Hi members of this list, I agree with Tom, I don't think size matters nowadays, and not in this order of magnitude. I don't also think it's safe to assume that if one wants to debug, having local vars, one is also already building openjfx (or it isn't a stretch). Thanks! -- Pedro Duque Vieira - https://www.pixelduke.com From r.lichtenberger at gmail.com Thu Jul 18 04:45:48 2019 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Thu, 18 Jul 2019 06:45:48 +0200 Subject: Debugging JavaFX In-Reply-To: References: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> <715f1ed4-d5b7-7dab-fac9-5f436e71c0a2@oracle.com> <2e33341d-0eea-27ba-45f8-5d6cc6e9e217@jugs.org> <05bc0108-7f82-0bb1-6026-83c082294919@bestsolution.at> Message-ID: Thanks for the information. Maybe something in my setup was wrong. I'd also appreciate if the default builds would contain debug information, this would make JavaFX much more "developer friendly". Robert Am Do., 18. Juli 2019 um 00:04 Uhr schrieb Kevin Rushforth < kevin.rushforth at oracle.com>: > I did a quick test and the difference in size is noticeable, but not > huge -- on the order of 10% larger with the local symbols. You could > file an enhancement to have a binary available with the local symbols > (or to add them to the default build), but I don't know whether it's > generally useful enough to justify it. Maybe Johan can weigh in on this > one? > > -- Kevin > > > On 7/17/2019 1:50 PM, Tom Eugelink wrote: > > I think I saw that one of the argument for not providing debug symbols > > was size... If there is anything I would not quickly compromise on > > nowadays is size. Even my smartwatch has gigabytes of internal > > storage. If size is an issue for an application, it is usually not > > caused by including debug symbols in a jar. > > > > > > On 17-7-2019 21:01, Tom Schindl wrote: > >> Well the main problem is that if there are no local var you can not set > >> conditional break points in the code, inject syserr logging to > >> understand what is going on and what your code does to FX. > >> > >> One could provide 2 artifacts one with and one without debug symbols. > >> > >> Tom > >> > >> On 17.07.19 19:12, Kevin Rushforth wrote: > >>> Mainly size. Generally if a developer is going to debug JavaFX to point > >>> of wanting to look at local variables, it doesn't seem a stretch for > >>> them to build JavaFX. > >>> > >>> -- Kevin > >>> > >>> > >>> On 7/17/2019 9:57 AM, Tom Schindl wrote: > >>>> so what is the reason to strip them (i guess it it size) it is > >>>> extremely > >>>> painful to don't see local-variables, have parameter names, arg1,arg2, > >>>> ... . > >>>> > >>>> Tom > >>>> > >>>> On 17.07.19 17:01, Kevin Rushforth wrote: > >>>>> When you say that don't see a problem, what exactly do you mean? > >>>>> If you > >>>>> are able to see the local variables in a production build, then that > >>>>> would in fact be surprising. The production builds, including EA > >>>>> builds, > >>>>> should be being built with "-PCONF=Release" which would exclude vars. > >>>>> Someone from Gluon should confirm. > >>>>> > >>>>> -- Kevin > >>>>> > >>>>> > >>>>> On 7/17/2019 7:56 AM, Michael Paus wrote: > >>>>>> Hi, > >>>>>> I don't see any problem of that kind with Eclipse, on MacOS, JavaFX > >>>>>> 13-ea 9 via Maven. > >>>>>> Michael > >>>>>> > >>>>>> Am 17.07.19 um 16:45 schrieb Kevin Rushforth: > >>>>>>> That should have been enough to enable local variable symbols. We > >>>>>>> have the following logic for JavaCompile tasks: > >>>>>>> > >>>>>>> compile.options.debugOptions.debugLevel = IS_DEBUG_JAVA ? > >>>>>>> "source,lines,vars" : "source,lines" > >>>>>>> > >>>>>>> IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. > >>>>>>> > >>>>>>> Maybe something else is stripping out the symbols. > >>>>>>> > >>>>>>> Has anyone else debugged JavaFX recently and tried to look at local > >>>>>>> vars? If not, I'll take a quick look later today. > >>>>>>> > >>>>>>> -- Kevin > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: > >>>>>>>> I'm trying to get to the bottom of some weird layout problems > >>>>>>>> in my > >>>>>>>> application. > >>>>>>>> > >>>>>>>> To that end I want/need to debug JavaFX classes. > >>>>>>>> > >>>>>>>> But when I step into JavaFX classes I don't see local variables or > >>>>>>>> parameter names. > >>>>>>>> > >>>>>>>> So I thought debug symbols are probably stripped from the official > >>>>>>>> builds. > >>>>>>>> > >>>>>>>> I rolled my own and tried > >>>>>>>> > >>>>>>>> CONF = Debug > >>>>>>>> > >>>>>>>> and > >>>>>>>> > >>>>>>>> CONF = DebugNative > >>>>>>>> > >>>>>>>> in gradle.properties, recompiled OpenJFX and integrated the > >>>>>>>> libraries > >>>>>>>> into a little eclipse testproject. > >>>>>>>> > >>>>>>>> But I still don't see parameter names or local variables. > >>>>>>>> > >>>>>>>> Is there something else I need to do in order to see them? > >>>>>>>> > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> > >>>>>>>> Robert > >>>>>>>> > >>>>>>>> > > > > From tbee at tbee.org Thu Jul 18 06:08:51 2019 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 18 Jul 2019 08:08:51 +0200 Subject: Debugging JavaFX In-Reply-To: References: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> <715f1ed4-d5b7-7dab-fac9-5f436e71c0a2@oracle.com> <2e33341d-0eea-27ba-45f8-5d6cc6e9e217@jugs.org> <05bc0108-7f82-0bb1-6026-83c082294919@bestsolution.at> Message-ID: <5c41752a-1378-3184-67ec-70664feaf375@tbee.org> Hm. Being able to just debug JavaFX will seriously lower the threshold for people to get on board. Personally if I run into a library that is behaving faulty and I need to download and compile it first, I'm already not very happy (it's a hassle). But ahm... cygwin, visual studio, directshow header files (on windows) is not "just type gradle". On 18-7-2019 06:45, Robert Lichtenberger wrote: > Thanks for the information. Maybe something in my setup was wrong. I'd also > appreciate if the default builds would contain debug information, this > would make JavaFX much more "developer friendly". > > Robert > > Am Do., 18. Juli 2019 um 00:04 Uhr schrieb Kevin Rushforth < > kevin.rushforth at oracle.com>: > >> I did a quick test and the difference in size is noticeable, but not >> huge -- on the order of 10% larger with the local symbols. You could >> file an enhancement to have a binary available with the local symbols >> (or to add them to the default build), but I don't know whether it's >> generally useful enough to justify it. Maybe Johan can weigh in on this >> one? >> >> -- Kevin >> >> >> On 7/17/2019 1:50 PM, Tom Eugelink wrote: >>> I think I saw that one of the argument for not providing debug symbols >>> was size... If there is anything I would not quickly compromise on >>> nowadays is size. Even my smartwatch has gigabytes of internal >>> storage. If size is an issue for an application, it is usually not >>> caused by including debug symbols in a jar. >>> >>> >>> On 17-7-2019 21:01, Tom Schindl wrote: >>>> Well the main problem is that if there are no local var you can not set >>>> conditional break points in the code, inject syserr logging to >>>> understand what is going on and what your code does to FX. >>>> >>>> One could provide 2 artifacts one with and one without debug symbols. >>>> >>>> Tom >>>> >>>> On 17.07.19 19:12, Kevin Rushforth wrote: >>>>> Mainly size. Generally if a developer is going to debug JavaFX to point >>>>> of wanting to look at local variables, it doesn't seem a stretch for >>>>> them to build JavaFX. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 7/17/2019 9:57 AM, Tom Schindl wrote: >>>>>> so what is the reason to strip them (i guess it it size) it is >>>>>> extremely >>>>>> painful to don't see local-variables, have parameter names, arg1,arg2, >>>>>> ... . >>>>>> >>>>>> Tom >>>>>> >>>>>> On 17.07.19 17:01, Kevin Rushforth wrote: >>>>>>> When you say that don't see a problem, what exactly do you mean? >>>>>>> If you >>>>>>> are able to see the local variables in a production build, then that >>>>>>> would in fact be surprising. The production builds, including EA >>>>>>> builds, >>>>>>> should be being built with "-PCONF=Release" which would exclude vars. >>>>>>> Someone from Gluon should confirm. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> On 7/17/2019 7:56 AM, Michael Paus wrote: >>>>>>>> Hi, >>>>>>>> I don't see any problem of that kind with Eclipse, on MacOS, JavaFX >>>>>>>> 13-ea 9 via Maven. >>>>>>>> Michael >>>>>>>> >>>>>>>> Am 17.07.19 um 16:45 schrieb Kevin Rushforth: >>>>>>>>> That should have been enough to enable local variable symbols. We >>>>>>>>> have the following logic for JavaCompile tasks: >>>>>>>>> >>>>>>>>> compile.options.debugOptions.debugLevel = IS_DEBUG_JAVA ? >>>>>>>>> "source,lines,vars" : "source,lines" >>>>>>>>> >>>>>>>>> IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. >>>>>>>>> >>>>>>>>> Maybe something else is stripping out the symbols. >>>>>>>>> >>>>>>>>> Has anyone else debugged JavaFX recently and tried to look at local >>>>>>>>> vars? If not, I'll take a quick look later today. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: >>>>>>>>>> I'm trying to get to the bottom of some weird layout problems >>>>>>>>>> in my >>>>>>>>>> application. >>>>>>>>>> >>>>>>>>>> To that end I want/need to debug JavaFX classes. >>>>>>>>>> >>>>>>>>>> But when I step into JavaFX classes I don't see local variables or >>>>>>>>>> parameter names. >>>>>>>>>> >>>>>>>>>> So I thought debug symbols are probably stripped from the official >>>>>>>>>> builds. >>>>>>>>>> >>>>>>>>>> I rolled my own and tried >>>>>>>>>> >>>>>>>>>> CONF = Debug >>>>>>>>>> >>>>>>>>>> and >>>>>>>>>> >>>>>>>>>> CONF = DebugNative >>>>>>>>>> >>>>>>>>>> in gradle.properties, recompiled OpenJFX and integrated the >>>>>>>>>> libraries >>>>>>>>>> into a little eclipse testproject. >>>>>>>>>> >>>>>>>>>> But I still don't see parameter names or local variables. >>>>>>>>>> >>>>>>>>>> Is there something else I need to do in order to see them? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> >>>>>>>>>> Robert >>>>>>>>>> >>>>>>>>>> >> From r.lichtenberger at gmail.com Thu Jul 18 06:18:12 2019 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Thu, 18 Jul 2019 08:18:12 +0200 Subject: Debugging JavaFX In-Reply-To: <5c41752a-1378-3184-67ec-70664feaf375@tbee.org> References: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> <715f1ed4-d5b7-7dab-fac9-5f436e71c0a2@oracle.com> <2e33341d-0eea-27ba-45f8-5d6cc6e9e217@jugs.org> <05bc0108-7f82-0bb1-6026-83c082294919@bestsolution.at> <5c41752a-1378-3184-67ec-70664feaf375@tbee.org> Message-ID: I started from scratch today and was able to compile and use JavaFX with debug information. When trying to start the test application an error was thrown: no glassgtk3 in java.library.path; Now thanks to the debugging information beeing present I was able to debug GtkApplication like a charm and found out that my machine (Fedora 30) didn't have gtk3-devel installed. To that end I suggest someone updates https://wiki.openjdk.java.net/pages/viewpage.action?pageId=8257548#BuildingOpenJFX-OracleEnterpriseLinux7andFedora21 and adds gtk3-devel to the list of required packages. The equivalent libgtk-3-dev is already there in the Ubuntu section. Best regards, Robert Am Do., 18. Juli 2019 um 08:09 Uhr schrieb Tom Eugelink : > Hm. Being able to just debug JavaFX will seriously lower the threshold for > people to get on board. Personally if I run into a library that is behaving > faulty and I need to download and compile it first, I'm already not very > happy (it's a hassle). But ahm... cygwin, visual studio, directshow header > files (on windows) is not "just type gradle". > > > On 18-7-2019 06:45, Robert Lichtenberger wrote: > > Thanks for the information. Maybe something in my setup was wrong. I'd > also > > appreciate if the default builds would contain debug information, this > > would make JavaFX much more "developer friendly". > > > > Robert > > > > Am Do., 18. Juli 2019 um 00:04 Uhr schrieb Kevin Rushforth < > > kevin.rushforth at oracle.com>: > > > >> I did a quick test and the difference in size is noticeable, but not > >> huge -- on the order of 10% larger with the local symbols. You could > >> file an enhancement to have a binary available with the local symbols > >> (or to add them to the default build), but I don't know whether it's > >> generally useful enough to justify it. Maybe Johan can weigh in on this > >> one? > >> > >> -- Kevin > >> > >> > >> On 7/17/2019 1:50 PM, Tom Eugelink wrote: > >>> I think I saw that one of the argument for not providing debug symbols > >>> was size... If there is anything I would not quickly compromise on > >>> nowadays is size. Even my smartwatch has gigabytes of internal > >>> storage. If size is an issue for an application, it is usually not > >>> caused by including debug symbols in a jar. > >>> > >>> > >>> On 17-7-2019 21:01, Tom Schindl wrote: > >>>> Well the main problem is that if there are no local var you can not > set > >>>> conditional break points in the code, inject syserr logging to > >>>> understand what is going on and what your code does to FX. > >>>> > >>>> One could provide 2 artifacts one with and one without debug symbols. > >>>> > >>>> Tom > >>>> > >>>> On 17.07.19 19:12, Kevin Rushforth wrote: > >>>>> Mainly size. Generally if a developer is going to debug JavaFX to > point > >>>>> of wanting to look at local variables, it doesn't seem a stretch for > >>>>> them to build JavaFX. > >>>>> > >>>>> -- Kevin > >>>>> > >>>>> > >>>>> On 7/17/2019 9:57 AM, Tom Schindl wrote: > >>>>>> so what is the reason to strip them (i guess it it size) it is > >>>>>> extremely > >>>>>> painful to don't see local-variables, have parameter names, > arg1,arg2, > >>>>>> ... . > >>>>>> > >>>>>> Tom > >>>>>> > >>>>>> On 17.07.19 17:01, Kevin Rushforth wrote: > >>>>>>> When you say that don't see a problem, what exactly do you mean? > >>>>>>> If you > >>>>>>> are able to see the local variables in a production build, then > that > >>>>>>> would in fact be surprising. The production builds, including EA > >>>>>>> builds, > >>>>>>> should be being built with "-PCONF=Release" which would exclude > vars. > >>>>>>> Someone from Gluon should confirm. > >>>>>>> > >>>>>>> -- Kevin > >>>>>>> > >>>>>>> > >>>>>>> On 7/17/2019 7:56 AM, Michael Paus wrote: > >>>>>>>> Hi, > >>>>>>>> I don't see any problem of that kind with Eclipse, on MacOS, > JavaFX > >>>>>>>> 13-ea 9 via Maven. > >>>>>>>> Michael > >>>>>>>> > >>>>>>>> Am 17.07.19 um 16:45 schrieb Kevin Rushforth: > >>>>>>>>> That should have been enough to enable local variable symbols. We > >>>>>>>>> have the following logic for JavaCompile tasks: > >>>>>>>>> > >>>>>>>>> compile.options.debugOptions.debugLevel = > IS_DEBUG_JAVA ? > >>>>>>>>> "source,lines,vars" : "source,lines" > >>>>>>>>> > >>>>>>>>> IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. > >>>>>>>>> > >>>>>>>>> Maybe something else is stripping out the symbols. > >>>>>>>>> > >>>>>>>>> Has anyone else debugged JavaFX recently and tried to look at > local > >>>>>>>>> vars? If not, I'll take a quick look later today. > >>>>>>>>> > >>>>>>>>> -- Kevin > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: > >>>>>>>>>> I'm trying to get to the bottom of some weird layout problems > >>>>>>>>>> in my > >>>>>>>>>> application. > >>>>>>>>>> > >>>>>>>>>> To that end I want/need to debug JavaFX classes. > >>>>>>>>>> > >>>>>>>>>> But when I step into JavaFX classes I don't see local variables > or > >>>>>>>>>> parameter names. > >>>>>>>>>> > >>>>>>>>>> So I thought debug symbols are probably stripped from the > official > >>>>>>>>>> builds. > >>>>>>>>>> > >>>>>>>>>> I rolled my own and tried > >>>>>>>>>> > >>>>>>>>>> CONF = Debug > >>>>>>>>>> > >>>>>>>>>> and > >>>>>>>>>> > >>>>>>>>>> CONF = DebugNative > >>>>>>>>>> > >>>>>>>>>> in gradle.properties, recompiled OpenJFX and integrated the > >>>>>>>>>> libraries > >>>>>>>>>> into a little eclipse testproject. > >>>>>>>>>> > >>>>>>>>>> But I still don't see parameter names or local variables. > >>>>>>>>>> > >>>>>>>>>> Is there something else I need to do in order to see them? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Best regards, > >>>>>>>>>> > >>>>>>>>>> Robert > >>>>>>>>>> > >>>>>>>>>> > >> > > From tom.schindl at bestsolution.at Thu Jul 18 08:15:33 2019 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 18 Jul 2019 10:15:33 +0200 Subject: Debugging JavaFX In-Reply-To: References: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> <715f1ed4-d5b7-7dab-fac9-5f436e71c0a2@oracle.com> <2e33341d-0eea-27ba-45f8-5d6cc6e9e217@jugs.org> <05bc0108-7f82-0bb1-6026-83c082294919@bestsolution.at> <5c41752a-1378-3184-67ec-70664feaf375@tbee.org> Message-ID: <49e4191e-9a82-e91a-666d-1422ab47d2b8@bestsolution.at> as requested by Kevin - https://bugs.openjdk.java.net/browse/JDK-8228357 - I filed in in the other category because i could not find a better matching one. Tom On 18.07.19 08:18, Robert Lichtenberger wrote: > I started from scratch today and was able to compile and use JavaFX with > debug information. > When trying to start the test application an error was thrown: no glassgtk3 > in java.library.path; > Now thanks to the debugging information beeing present I was able to debug > GtkApplication like a charm and found out that my machine (Fedora 30) > didn't have gtk3-devel installed. > > To that end I suggest someone updates > https://wiki.openjdk.java.net/pages/viewpage.action?pageId=8257548#BuildingOpenJFX-OracleEnterpriseLinux7andFedora21 > and adds gtk3-devel to the list of required packages. The equivalent > libgtk-3-dev is already there in the Ubuntu section. > > Best regards, > Robert > > Am Do., 18. Juli 2019 um 08:09 Uhr schrieb Tom Eugelink : > >> Hm. Being able to just debug JavaFX will seriously lower the threshold for >> people to get on board. Personally if I run into a library that is behaving >> faulty and I need to download and compile it first, I'm already not very >> happy (it's a hassle). But ahm... cygwin, visual studio, directshow header >> files (on windows) is not "just type gradle". >> >> >> On 18-7-2019 06:45, Robert Lichtenberger wrote: >>> Thanks for the information. Maybe something in my setup was wrong. I'd >> also >>> appreciate if the default builds would contain debug information, this >>> would make JavaFX much more "developer friendly". >>> >>> Robert >>> >>> Am Do., 18. Juli 2019 um 00:04 Uhr schrieb Kevin Rushforth < >>> kevin.rushforth at oracle.com>: >>> >>>> I did a quick test and the difference in size is noticeable, but not >>>> huge -- on the order of 10% larger with the local symbols. You could >>>> file an enhancement to have a binary available with the local symbols >>>> (or to add them to the default build), but I don't know whether it's >>>> generally useful enough to justify it. Maybe Johan can weigh in on this >>>> one? >>>> >>>> -- Kevin >>>> >>>> >>>> On 7/17/2019 1:50 PM, Tom Eugelink wrote: >>>>> I think I saw that one of the argument for not providing debug symbols >>>>> was size... If there is anything I would not quickly compromise on >>>>> nowadays is size. Even my smartwatch has gigabytes of internal >>>>> storage. If size is an issue for an application, it is usually not >>>>> caused by including debug symbols in a jar. >>>>> >>>>> >>>>> On 17-7-2019 21:01, Tom Schindl wrote: >>>>>> Well the main problem is that if there are no local var you can not >> set >>>>>> conditional break points in the code, inject syserr logging to >>>>>> understand what is going on and what your code does to FX. >>>>>> >>>>>> One could provide 2 artifacts one with and one without debug symbols. >>>>>> >>>>>> Tom >>>>>> >>>>>> On 17.07.19 19:12, Kevin Rushforth wrote: >>>>>>> Mainly size. Generally if a developer is going to debug JavaFX to >> point >>>>>>> of wanting to look at local variables, it doesn't seem a stretch for >>>>>>> them to build JavaFX. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> On 7/17/2019 9:57 AM, Tom Schindl wrote: >>>>>>>> so what is the reason to strip them (i guess it it size) it is >>>>>>>> extremely >>>>>>>> painful to don't see local-variables, have parameter names, >> arg1,arg2, >>>>>>>> ... . >>>>>>>> >>>>>>>> Tom >>>>>>>> >>>>>>>> On 17.07.19 17:01, Kevin Rushforth wrote: >>>>>>>>> When you say that don't see a problem, what exactly do you mean? >>>>>>>>> If you >>>>>>>>> are able to see the local variables in a production build, then >> that >>>>>>>>> would in fact be surprising. The production builds, including EA >>>>>>>>> builds, >>>>>>>>> should be being built with "-PCONF=Release" which would exclude >> vars. >>>>>>>>> Someone from Gluon should confirm. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/17/2019 7:56 AM, Michael Paus wrote: >>>>>>>>>> Hi, >>>>>>>>>> I don't see any problem of that kind with Eclipse, on MacOS, >> JavaFX >>>>>>>>>> 13-ea 9 via Maven. >>>>>>>>>> Michael >>>>>>>>>> >>>>>>>>>> Am 17.07.19 um 16:45 schrieb Kevin Rushforth: >>>>>>>>>>> That should have been enough to enable local variable symbols. We >>>>>>>>>>> have the following logic for JavaCompile tasks: >>>>>>>>>>> >>>>>>>>>>> compile.options.debugOptions.debugLevel = >> IS_DEBUG_JAVA ? >>>>>>>>>>> "source,lines,vars" : "source,lines" >>>>>>>>>>> >>>>>>>>>>> IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. >>>>>>>>>>> >>>>>>>>>>> Maybe something else is stripping out the symbols. >>>>>>>>>>> >>>>>>>>>>> Has anyone else debugged JavaFX recently and tried to look at >> local >>>>>>>>>>> vars? If not, I'll take a quick look later today. >>>>>>>>>>> >>>>>>>>>>> -- Kevin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: >>>>>>>>>>>> I'm trying to get to the bottom of some weird layout problems >>>>>>>>>>>> in my >>>>>>>>>>>> application. >>>>>>>>>>>> >>>>>>>>>>>> To that end I want/need to debug JavaFX classes. >>>>>>>>>>>> >>>>>>>>>>>> But when I step into JavaFX classes I don't see local variables >> or >>>>>>>>>>>> parameter names. >>>>>>>>>>>> >>>>>>>>>>>> So I thought debug symbols are probably stripped from the >> official >>>>>>>>>>>> builds. >>>>>>>>>>>> >>>>>>>>>>>> I rolled my own and tried >>>>>>>>>>>> >>>>>>>>>>>> CONF = Debug >>>>>>>>>>>> >>>>>>>>>>>> and >>>>>>>>>>>> >>>>>>>>>>>> CONF = DebugNative >>>>>>>>>>>> >>>>>>>>>>>> in gradle.properties, recompiled OpenJFX and integrated the >>>>>>>>>>>> libraries >>>>>>>>>>>> into a little eclipse testproject. >>>>>>>>>>>> >>>>>>>>>>>> But I still don't see parameter names or local variables. >>>>>>>>>>>> >>>>>>>>>>>> Is there something else I need to do in order to see them? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> >>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> >>>> >> >> -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From kevin.rushforth at oracle.com Thu Jul 18 12:25:10 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 18 Jul 2019 05:25:10 -0700 Subject: Debugging JavaFX In-Reply-To: <5c41752a-1378-3184-67ec-70664feaf375@tbee.org> References: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> <715f1ed4-d5b7-7dab-fac9-5f436e71c0a2@oracle.com> <2e33341d-0eea-27ba-45f8-5d6cc6e9e217@jugs.org> <05bc0108-7f82-0bb1-6026-83c082294919@bestsolution.at> <5c41752a-1378-3184-67ec-70664feaf375@tbee.org> Message-ID: I see that Tom Schindl filed the Enhancement request. https://bugs.openjdk.java.net/browse/JDK-8228357 -- Kevin On 7/17/2019 11:08 PM, Tom Eugelink wrote: > Hm. Being able to just debug JavaFX will seriously lower the threshold > for people to get on board. Personally if I run into a library that is > behaving faulty and I need to download and compile it first, I'm > already not very happy (it's a hassle). But ahm... cygwin, visual > studio, directshow header files (on windows) is not "just type gradle". > > > On 18-7-2019 06:45, Robert Lichtenberger wrote: >> Thanks for the information. Maybe something in my setup was wrong. >> I'd also >> appreciate if the default builds would contain debug information, this >> would make JavaFX much more "developer friendly". >> >> Robert >> >> Am Do., 18. Juli 2019 um 00:04 Uhr schrieb Kevin Rushforth < >> kevin.rushforth at oracle.com>: >> >>> I did a quick test and the difference in size is noticeable, but not >>> huge -- on the order of 10% larger with the local symbols. You could >>> file an enhancement to have a binary available with the local symbols >>> (or to add them to the default build), but I don't know whether it's >>> generally useful enough to justify it. Maybe Johan can weigh in on this >>> one? >>> >>> -- Kevin >>> >>> >>> On 7/17/2019 1:50 PM, Tom Eugelink wrote: >>>> I think I saw that one of the argument for not providing debug symbols >>>> was size... If there is anything I would not quickly compromise on >>>> nowadays is size. Even my smartwatch has gigabytes of internal >>>> storage. If size is an issue for an application, it is usually not >>>> caused by including debug symbols in a jar. >>>> >>>> >>>> On 17-7-2019 21:01, Tom Schindl wrote: >>>>> Well the main problem is that if there are no local var you can >>>>> not set >>>>> conditional break points in the code, inject syserr logging to >>>>> understand what is going on and what your code does to FX. >>>>> >>>>> One could provide 2 artifacts one with and one without debug symbols. >>>>> >>>>> Tom >>>>> >>>>> On 17.07.19 19:12, Kevin Rushforth wrote: >>>>>> Mainly size. Generally if a developer is going to debug JavaFX to >>>>>> point >>>>>> of wanting to look at local variables, it doesn't seem a stretch for >>>>>> them to build JavaFX. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> On 7/17/2019 9:57 AM, Tom Schindl wrote: >>>>>>> so what is the reason to strip them (i guess it it size) it is >>>>>>> extremely >>>>>>> painful to don't see local-variables, have parameter names, >>>>>>> arg1,arg2, >>>>>>> ... . >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> On 17.07.19 17:01, Kevin Rushforth wrote: >>>>>>>> When you say that don't see a problem, what exactly do you mean? >>>>>>>> If you >>>>>>>> are able to see the local variables in a production build, then >>>>>>>> that >>>>>>>> would in fact be surprising. The production builds, including EA >>>>>>>> builds, >>>>>>>> should be being built with "-PCONF=Release" which would exclude >>>>>>>> vars. >>>>>>>> Someone from Gluon should confirm. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> On 7/17/2019 7:56 AM, Michael Paus wrote: >>>>>>>>> Hi, >>>>>>>>> I don't see any problem of that kind with Eclipse, on MacOS, >>>>>>>>> JavaFX >>>>>>>>> 13-ea 9 via Maven. >>>>>>>>> Michael >>>>>>>>> >>>>>>>>> Am 17.07.19 um 16:45 schrieb Kevin Rushforth: >>>>>>>>>> That should have been enough to enable local variable >>>>>>>>>> symbols. We >>>>>>>>>> have the following logic for JavaCompile tasks: >>>>>>>>>> >>>>>>>>>> compile.options.debugOptions.debugLevel = IS_DEBUG_JAVA ? >>>>>>>>>> "source,lines,vars" : "source,lines" >>>>>>>>>> >>>>>>>>>> IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. >>>>>>>>>> >>>>>>>>>> Maybe something else is stripping out the symbols. >>>>>>>>>> >>>>>>>>>> Has anyone else debugged JavaFX recently and tried to look at >>>>>>>>>> local >>>>>>>>>> vars? If not, I'll take a quick look later today. >>>>>>>>>> >>>>>>>>>> -- Kevin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: >>>>>>>>>>> I'm trying to get to the bottom of some weird layout problems >>>>>>>>>>> in my >>>>>>>>>>> application. >>>>>>>>>>> >>>>>>>>>>> To that end I want/need to debug JavaFX classes. >>>>>>>>>>> >>>>>>>>>>> But when I step into JavaFX classes I don't see local >>>>>>>>>>> variables or >>>>>>>>>>> parameter names. >>>>>>>>>>> >>>>>>>>>>> So I thought debug symbols are probably stripped from the >>>>>>>>>>> official >>>>>>>>>>> builds. >>>>>>>>>>> >>>>>>>>>>> I rolled my own and tried >>>>>>>>>>> >>>>>>>>>>> ??????? CONF = Debug >>>>>>>>>>> >>>>>>>>>>> and >>>>>>>>>>> >>>>>>>>>>> ??????? CONF = DebugNative >>>>>>>>>>> >>>>>>>>>>> in gradle.properties, recompiled OpenJFX and integrated the >>>>>>>>>>> libraries >>>>>>>>>>> into a little eclipse testproject. >>>>>>>>>>> >>>>>>>>>>> But I still don't see parameter names or local variables. >>>>>>>>>>> >>>>>>>>>>> Is there something else I need to do in order to see them? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> >>>>>>>>>>> Robert >>>>>>>>>>> >>>>>>>>>>> >>> > From kevin.rushforth at oracle.com Thu Jul 18 12:26:06 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 18 Jul 2019 05:26:06 -0700 Subject: Debugging JavaFX In-Reply-To: References: <3d07bee6-b0ff-7252-9c4d-03253eb1deed@gmail.com> <715f1ed4-d5b7-7dab-fac9-5f436e71c0a2@oracle.com> <2e33341d-0eea-27ba-45f8-5d6cc6e9e217@jugs.org> <05bc0108-7f82-0bb1-6026-83c082294919@bestsolution.at> <5c41752a-1378-3184-67ec-70664feaf375@tbee.org> Message-ID: <46b17fcb-1ac5-ca32-1e84-e84ac2436cf8@oracle.com> Regarding the GTK3 dependency, I filed JDK-8227808 [1] a couple days ago to fail at build time if the GTK3 libraries aren't present, rather than generating a library that doesn't run. I also just updated the Wiki. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8227808 On 7/17/2019 11:18 PM, Robert Lichtenberger wrote: > I started from scratch today and was able to compile and use JavaFX with > debug information. > When trying to start the test application an error was thrown: no glassgtk3 > in java.library.path; > Now thanks to the debugging information beeing present I was able to debug > GtkApplication like a charm and found out that my machine (Fedora 30) > didn't have gtk3-devel installed. > > To that end I suggest someone updates > https://wiki.openjdk.java.net/pages/viewpage.action?pageId=8257548#BuildingOpenJFX-OracleEnterpriseLinux7andFedora21 > and adds gtk3-devel to the list of required packages. The equivalent > libgtk-3-dev is already there in the Ubuntu section. > > Best regards, > Robert > > Am Do., 18. Juli 2019 um 08:09 Uhr schrieb Tom Eugelink : > >> Hm. Being able to just debug JavaFX will seriously lower the threshold for >> people to get on board. Personally if I run into a library that is behaving >> faulty and I need to download and compile it first, I'm already not very >> happy (it's a hassle). But ahm... cygwin, visual studio, directshow header >> files (on windows) is not "just type gradle". >> >> >> On 18-7-2019 06:45, Robert Lichtenberger wrote: >>> Thanks for the information. Maybe something in my setup was wrong. I'd >> also >>> appreciate if the default builds would contain debug information, this >>> would make JavaFX much more "developer friendly". >>> >>> Robert >>> >>> Am Do., 18. Juli 2019 um 00:04 Uhr schrieb Kevin Rushforth < >>> kevin.rushforth at oracle.com>: >>> >>>> I did a quick test and the difference in size is noticeable, but not >>>> huge -- on the order of 10% larger with the local symbols. You could >>>> file an enhancement to have a binary available with the local symbols >>>> (or to add them to the default build), but I don't know whether it's >>>> generally useful enough to justify it. Maybe Johan can weigh in on this >>>> one? >>>> >>>> -- Kevin >>>> >>>> >>>> On 7/17/2019 1:50 PM, Tom Eugelink wrote: >>>>> I think I saw that one of the argument for not providing debug symbols >>>>> was size... If there is anything I would not quickly compromise on >>>>> nowadays is size. Even my smartwatch has gigabytes of internal >>>>> storage. If size is an issue for an application, it is usually not >>>>> caused by including debug symbols in a jar. >>>>> >>>>> >>>>> On 17-7-2019 21:01, Tom Schindl wrote: >>>>>> Well the main problem is that if there are no local var you can not >> set >>>>>> conditional break points in the code, inject syserr logging to >>>>>> understand what is going on and what your code does to FX. >>>>>> >>>>>> One could provide 2 artifacts one with and one without debug symbols. >>>>>> >>>>>> Tom >>>>>> >>>>>> On 17.07.19 19:12, Kevin Rushforth wrote: >>>>>>> Mainly size. Generally if a developer is going to debug JavaFX to >> point >>>>>>> of wanting to look at local variables, it doesn't seem a stretch for >>>>>>> them to build JavaFX. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> On 7/17/2019 9:57 AM, Tom Schindl wrote: >>>>>>>> so what is the reason to strip them (i guess it it size) it is >>>>>>>> extremely >>>>>>>> painful to don't see local-variables, have parameter names, >> arg1,arg2, >>>>>>>> ... . >>>>>>>> >>>>>>>> Tom >>>>>>>> >>>>>>>> On 17.07.19 17:01, Kevin Rushforth wrote: >>>>>>>>> When you say that don't see a problem, what exactly do you mean? >>>>>>>>> If you >>>>>>>>> are able to see the local variables in a production build, then >> that >>>>>>>>> would in fact be surprising. The production builds, including EA >>>>>>>>> builds, >>>>>>>>> should be being built with "-PCONF=Release" which would exclude >> vars. >>>>>>>>> Someone from Gluon should confirm. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/17/2019 7:56 AM, Michael Paus wrote: >>>>>>>>>> Hi, >>>>>>>>>> I don't see any problem of that kind with Eclipse, on MacOS, >> JavaFX >>>>>>>>>> 13-ea 9 via Maven. >>>>>>>>>> Michael >>>>>>>>>> >>>>>>>>>> Am 17.07.19 um 16:45 schrieb Kevin Rushforth: >>>>>>>>>>> That should have been enough to enable local variable symbols. We >>>>>>>>>>> have the following logic for JavaCompile tasks: >>>>>>>>>>> >>>>>>>>>>> compile.options.debugOptions.debugLevel = >> IS_DEBUG_JAVA ? >>>>>>>>>>> "source,lines,vars" : "source,lines" >>>>>>>>>>> >>>>>>>>>>> IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. >>>>>>>>>>> >>>>>>>>>>> Maybe something else is stripping out the symbols. >>>>>>>>>>> >>>>>>>>>>> Has anyone else debugged JavaFX recently and tried to look at >> local >>>>>>>>>>> vars? If not, I'll take a quick look later today. >>>>>>>>>>> >>>>>>>>>>> -- Kevin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: >>>>>>>>>>>> I'm trying to get to the bottom of some weird layout problems >>>>>>>>>>>> in my >>>>>>>>>>>> application. >>>>>>>>>>>> >>>>>>>>>>>> To that end I want/need to debug JavaFX classes. >>>>>>>>>>>> >>>>>>>>>>>> But when I step into JavaFX classes I don't see local variables >> or >>>>>>>>>>>> parameter names. >>>>>>>>>>>> >>>>>>>>>>>> So I thought debug symbols are probably stripped from the >> official >>>>>>>>>>>> builds. >>>>>>>>>>>> >>>>>>>>>>>> I rolled my own and tried >>>>>>>>>>>> >>>>>>>>>>>> CONF = Debug >>>>>>>>>>>> >>>>>>>>>>>> and >>>>>>>>>>>> >>>>>>>>>>>> CONF = DebugNative >>>>>>>>>>>> >>>>>>>>>>>> in gradle.properties, recompiled OpenJFX and integrated the >>>>>>>>>>>> libraries >>>>>>>>>>>> into a little eclipse testproject. >>>>>>>>>>>> >>>>>>>>>>>> But I still don't see parameter names or local variables. >>>>>>>>>>>> >>>>>>>>>>>> Is there something else I need to do in order to see them? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> >>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> >> From kevin.rushforth at oracle.com Thu Jul 18 23:41:14 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 18 Jul 2019 16:41:14 -0700 Subject: [13] RFR: JDK-8209086: Some javafx.web files are missing GPLv2+Classpath copyright header Message-ID: <510fcdb2-91c7-1104-d267-ec2e5118e10b@oracle.com> Please review this fix to add a GPLv2+Classpath copyright header to those javafx.web native files that are missing the header. https://bugs.openjdk.java.net/browse/JDK-8209086 https://github.com/javafxports/openjdk-jfx/pull/533 -- Kevin From johan.vos at gluonhq.com Fri Jul 19 08:34:31 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 19 Jul 2019 10:34:31 +0200 Subject: RFR: JDK-8222839 : increase security version for 12-dev Message-ID: Hi Kevin, Please review https://bugs.openjdk.java.net/browse/JDK-8228422 with webrev at http://cr.openjdk.java.net/~jvos/8228422/webrev.00/ which increases the security version in the 12-dev repository. Thanks, - Johan From johan.vos at gluonhq.com Fri Jul 19 08:48:27 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 19 Jul 2019 10:48:27 +0200 Subject: RFR: JDK-8228424: release notes for 12.0.2 Message-ID: Hi Kevin, Please review https://bugs.openjdk.java.net/browse/JDK-8228424 with webrev http://cr.openjdk.java.net/~jvos/8228424/webrev.00/ which contains release notes for 12.0.2 Thanks, - Johan From bourges.laurent at gmail.com Fri Jul 19 13:55:47 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 19 Jul 2019 15:55:47 +0200 Subject: RFR: 8226789: Path rendered incorrectly when it goes outside the clipping region Message-ID: Hi, Please review this bug fix in Marlin renderer's path clipper :https://bugs.openjdk.java.net/browse/JDK-8226789https://github.com/javafxports/openjdk-jfx/pull/534 PS: I will propose another fix soon to JDK14 / Marlin renderer (java2d) Laurent From samir.hadzic.pro at gmail.com Fri Jul 19 15:43:16 2019 From: samir.hadzic.pro at gmail.com (Sam') Date: Fri, 19 Jul 2019 17:43:16 +0200 Subject: RFR: JDK-8207957 : TableSkinUtils should not contain actual code implementation Message-ID: Please review the fix for "TableSkinUtils should not contain actual code implementation": https://bugs.openjdk.java.net/browse/JDK-8207957https://github.com/javafxports/openjdk-jfx/pull/289 From nlisker at gmail.com Sat Jul 20 20:38:57 2019 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 20 Jul 2019 23:38:57 +0300 Subject: Review Request: JDK-8221377: Fix mistakes in FX API docs Message-ID: Hi Kevin, Please review the fix for: https://bugs.openjdk.java.net/browse/JDK-8221377 http://cr.openjdk.java.net/~nlisker/8221377/webrev.00/ Thanks, Nir From kevin.rushforth at oracle.com Mon Jul 22 13:11:34 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 22 Jul 2019 06:11:34 -0700 Subject: [13] RFR: JDK-8223722: Cleanup .gitignore file Message-ID: Please review the following simple fix to cleanup the .gitignore file: https://bugs.openjdk.java.net/browse/JDK-8223722 https://github.com/javafxports/openjdk-jfx/pull/535 -- Kevin From johan at lodgon.com Mon Jul 22 13:32:55 2019 From: johan at lodgon.com (Johan Vos) Date: Mon, 22 Jul 2019 15:32:55 +0200 Subject: [13] RFR: JDK-8223722: Cleanup .gitignore file In-Reply-To: References: Message-ID: +1 Op ma 22 jul. 2019 om 15:25 schreef Kevin Rushforth < kevin.rushforth at oracle.com>: > Please review the following simple fix to cleanup the .gitignore file: > > https://bugs.openjdk.java.net/browse/JDK-8223722 > https://github.com/javafxports/openjdk-jfx/pull/535 > > -- Kevin > > From kevin.rushforth at oracle.com Mon Jul 22 19:57:33 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 22 Jul 2019 12:57:33 -0700 Subject: [13] RFR: JDK-8223722: Cleanup .gitignore file In-Reply-To: References: Message-ID: <8fc0f861-64a6-5cb2-4075-5628985ca909@oracle.com> Thanks. I ended up pushing this into jfx-dev for openjfx14. Since developers should be working in the `develop` branch, I wasn't sure it was worth pushing it to 13-dev (for the jfx-13 branch). I can pull it into 13-dev if you want me to, though. Let me know. -- Kevin On 7/22/2019 6:32 AM, Johan Vos wrote: > +1 > > Op ma 22 jul. 2019 om 15:25 schreef Kevin Rushforth > >: > > Please review the following simple fix to cleanup the .gitignore file: > > https://bugs.openjdk.java.net/browse/JDK-8223722 > https://github.com/javafxports/openjdk-jfx/pull/535 > > -- Kevin > From johan at lodgon.com Mon Jul 22 20:00:01 2019 From: johan at lodgon.com (Johan Vos) Date: Mon, 22 Jul 2019 22:00:01 +0200 Subject: [13] RFR: JDK-8223722: Cleanup .gitignore file In-Reply-To: <8fc0f861-64a6-5cb2-4075-5628985ca909@oracle.com> References: <8fc0f861-64a6-5cb2-4075-5628985ca909@oracle.com> Message-ID: I don't think it's worth the administrative effort (of pulling it into 13-dev). There won't be many commits in the 13 branch, so I'm ok with having it in 14 and beyond. - Johan Op ma 22 jul. 2019 om 21:57 schreef Kevin Rushforth < kevin.rushforth at oracle.com>: > Thanks. I ended up pushing this into jfx-dev for openjfx14. Since > developers should be working in the `develop` branch, I wasn't sure it was > worth pushing it to 13-dev (for the jfx-13 branch). I can pull it into > 13-dev if you want me to, though. Let me know. > > -- Kevin > > > On 7/22/2019 6:32 AM, Johan Vos wrote: > > +1 > > Op ma 22 jul. 2019 om 15:25 schreef Kevin Rushforth < > kevin.rushforth at oracle.com>: > >> Please review the following simple fix to cleanup the .gitignore file: >> >> https://bugs.openjdk.java.net/browse/JDK-8223722 >> https://github.com/javafxports/openjdk-jfx/pull/535 >> >> -- Kevin >> >> > From kevin.rushforth at oracle.com Fri Jul 26 20:47:42 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 26 Jul 2019 13:47:42 -0700 Subject: Proposed schedule for JavaFX 13 In-Reply-To: <7fd7add2-96de-a3d3-6542-056070f79422@oracle.com> References: <7fd7add2-96de-a3d3-6542-056070f79422@oracle.com> Message-ID: <1defff23-4fbc-8b18-640d-bd26ae613580@oracle.com> As a reminder, the RDP2 date for JavaFX 13 is on Monday, August 5, at 23:59 Pacific time. This is the deadline for all P3-P4 bugs for JavaFX 13. Please allow sufficient time for your review to complete ahead of that deadline. During RDP2 P1-P2 bugs can be fixed for JavaFX 13 with approval, as was done in previous releases. Doc-only bugs and test-only bugs of any priority may still be fixed during RDP2. -- Kevin On 3/30/2019 9:40 AM, Kevin Rushforth wrote: > Here is the proposed schedule for JavaFX 13. > > RDP1: Jul 8, 2019 (aka ?feature freeze?) > RDP2: Aug 5, 2019 > Freeze: Aug 26, 2019 > GA: September 10, 2019 > > We plan to fork a 13-dev stabilization repo at RDP1. The GA date is > one week ahead of JDK 13, matching what we did for 12. > > Please let Johan or me know if you have any questions. > > -- Kevin From thiago.sayao at clamed.com.br Sun Jul 28 20:00:22 2019 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Sun, 28 Jul 2019 20:00:22 +0000 Subject: Help for fixing JDK-8227366 Message-ID: Hi, I have been investigating: https://bugs.openjdk.java.net/browse/JDK-8227366 The problem is the focus event gets fired for all windows when a window is closed, so it messes up with "last window" tracking. It also causes unnecessary events. On com.sun.javafx.tk.quantum.GlassStage: void windowsSetEnabled(boolean enabled) { // TODO: Need to solve RT-12605: // If Window #1 pops up an APPLICATION modal dialog #2 it should block // Window #1, but will also block Window #3, #4, etc., unless those // windows are descendants of #2. // Make a copy of the windows list, since it could change as the result // of a child window being closed when the parent is closed. for (GlassStage window : windows.toArray(new GlassStage[windows.size()])) { if (window != this && windows.contains(window)) { window.setPlatformEnabled(enabled); } } } It loops thru windows and calls setPlatformEnabled. On com.sun.javafx.tk.quantum.WindowStage: protected void setPlatformEnabled(boolean enabled) { super.setPlatformEnabled(enabled); if (platformWindow != null) { platformWindow.setEnabled(enabled); } if (enabled) { // Check if window is really enabled - to handle nested case if (platformWindow != null && platformWindow.isEnabled()) { requestToFront(); } } else { removeActiveWindow(this); } } It calls requestToFront(); // Note: This method is required to workaround a glass issue mentioned in RT-12607 protected void requestToFront() { if (platformWindow != null) { platformWindow.toFront(); platformWindow.requestFocus(); } } Which calls requestFocus(); As it's called on each window, it will bring each window to front. I find this weird. Any ideas why this is necessary? if (enabled) { // Check if window is really enabled - to handle nested case if (platformWindow != null && platformWindow.isEnabled()) { requestToFront(); } } Seems wrong to me. From Vladislav.Protsenko at king.com Tue Jul 30 09:47:35 2019 From: Vladislav.Protsenko at king.com (Vladislav Protsenko) Date: Tue, 30 Jul 2019 09:47:35 +0000 Subject: RFR: 8179097: NPE in MenuButtonSkinBase Message-ID: Please review the fix for NPE in MenuButtonSkinBase: https://bugs.openjdk.java.net/browse/JDK-8179097 https://github.com/javafxports/openjdk-jfx/pull/544 From guru.hb at oracle.com Tue Jul 30 16:00:05 2019 From: guru.hb at oracle.com (Guru) Date: Tue, 30 Jul 2019 21:30:05 +0530 Subject: RFR: JDK-8227431: [Windows] Fix assertion failure on X86 32-bit when enabling CLOOP based JavaScript interpreter Message-ID: <24D8BDF9-CE7D-43A6-9FDC-BBD13082047A@oracle.com> Please review the fix for JBS : https://bugs.openjdk.java.net/browse/JDK-8227431 PR : https://github.com/javafxports/openjdk-jfx/pull/545 Thanks, Guru From johan.vos at gluonhq.com Wed Jul 31 09:24:42 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 31 Jul 2019 11:24:42 +0200 Subject: Platform dependent behavior in Platform.startup() Message-ID: Hi, A pattern I increasingly use is to add JavaFX functionality to existing non-JavaFX applications. Rather than adding a class that extends javafx.application.Application, I add some code to an existing class, like this: javafx.platform.Platform.startup(() -> {System.err.println("JavaFX started");}); javafx.platform.Platform.runLater(() -> {Stage, Scene,... }); I noticed that having Platform.startup() in a class initialiser works fine on Linux/Windows, but fails on Mac when a lambda is passed to startup(). The reason for this is that on Mac, the main thread that starts Glass blocks until Glass has been started. But starting Glass also contains running the argument passed to startup(). In case this is a lambda, this requires the encapsulating class to be initialized -- but initializing this class is happening already but blocked on Glass being started. The other platforms (Windows/Linux) are less strict. They don't block on Glass being started (including running the Runnable passed to startup) before they return. I created issue https://github.com/javafxports/openjdk-jfx/issues/542 for this and I propose to fix it via PR https://github.com/javafxports/openjdk-jfx/pull/543 which considers Glass to be started *before* the supplied runnable is executed. - Johan From kevin.rushforth at oracle.com Wed Jul 31 13:03:44 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 31 Jul 2019 06:03:44 -0700 Subject: Platform dependent behavior in Platform.startup() In-Reply-To: References: Message-ID: While there is always a danger in calling a method that runs a lambda from a static init method, this seems like a case that should work. The current Mac implementation precludes returning from Platform::startup until after the Runnable passed into that method has completed and returned, which is not what was intended or expected. Your solution seems like a good one, although it will need to be well-tested. -- Kevin On 7/31/2019 2:24 AM, Johan Vos wrote: > Hi, > > A pattern I increasingly use is to add JavaFX functionality to existing > non-JavaFX applications. Rather than adding a class that extends > javafx.application.Application, I add some code to an existing class, like > this: > > javafx.platform.Platform.startup(() -> {System.err.println("JavaFX > started");}); > javafx.platform.Platform.runLater(() -> {Stage, Scene,... }); > > I noticed that having Platform.startup() in a class initialiser works fine > on Linux/Windows, but fails on Mac when a lambda is passed to startup(). > > The reason for this is that on Mac, the main thread that starts Glass > blocks until Glass has been started. > But starting Glass also contains running the argument passed to startup(). > In case this is a lambda, this requires the encapsulating class to be > initialized -- but initializing this class is happening already but blocked > on Glass being started. > > The other platforms (Windows/Linux) are less strict. They don't block on > Glass being started (including running the Runnable passed to startup) > before they return. > > I created issue https://github.com/javafxports/openjdk-jfx/issues/542 for > this and I propose to fix it via PR > https://github.com/javafxports/openjdk-jfx/pull/543 which considers Glass > to be started *before* the supplied runnable is executed. > > - Johan From thiago.sayao at clamed.com.br Wed Jul 31 14:12:27 2019 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Wed, 31 Jul 2019 14:12:27 +0000 Subject: RFR: JDK-8227366: Wrong stage gets focused after modal stage creation Message-ID: Please, review (and remove WIP): https://github.com/javafxports/openjdk-jfx/pull/520 https://bugs.openjdk.java.net/browse/JDK-8227366 Thanks.